Migrating resources between different Azure subscriptions

I have a few questions for the Azure gurus out there. I work for a software development house and I have been asked with coming up with our Azure infrastructure. The idea I had is to set up three Pay-As-You-Go subcriptions for the following departments:

1) Production (live environment). 2) Quality Assurance. 3) Testing.

My questions are:

1) When creating resources such as websites; virtual machines et al, can they be migrated between the various subscriptions? Here's a scenario: let's say we're launching a new application but first we need to test it. So we first place it in Testing. Once rigorous testing has been carried out, we move it to Quality Assurance. Afterwards, we move it to Production (live environment) when all quality checks have been exhausted. 2) I am also developing a security matrix where a user in one department cannot alter anything in another department.

What say you ladies & gents? Is it feasible?

Michael - the migration process you use will depend very much on the underlying infrastructure / service you are using.

As a starting point I'd suggest looking at how you can use build services to auto-deploy software you build. The MSDN documentation is a good starting point.

• Websites and Cloud Services (Web or Worker Roles): you will need to re-deploy your code to the appropriate instance in the right subscription. You can't "move" the underlying hosting infrastructure.
• Services hosted on Virtual Machines: you can move VMs between subscriptions but it requires a fair amount of effort depending on what other dependencies you have (networks, databases, etc). Your best bet is to try and take the same approach you would for websites / cloud services.
• Azure SQL Database: you need to backup / restore the database between the subscriptions.
• Other Azure Services: will depend very much on what is deployed (sorry if this one is vague but there's a lot of moving pieces in Azure).

Typically finding ways to script or automate the deployment / redeployment of any solutions you build would be time well spent in your scenario.

We use Visual Studio Online (VSO) for automated builds and deployments to our different azure environments. This would work whether you're separating your environments by different subscription or using different Resource Groups in the same subscription.

Our setup is that every code check-in spins off a build, runs the unit tests, and if successful triggers deploys to the Test environment.

Then our QA department routinely queue's a build through VSO selecting a specific changeset/date. If the build and unit tests are successful, this triggers a deploy to QA. This build also technically builds for prod, but doesn't deploy to prod.

They do all their Quality Assurance work, and if all is golden they submit their approval for their side of the gatekeeper logic built-in to VSO. We then have it setup so 2 other people have to sign off on that build being pushed to production (which can be immediate or scheduled).

If you're on premise, you can instead use their TFS which essentially is the same thing.

TLDR; You can accomplish this through VSO, and integrate it with Azure Active Directory for authentication and control.