Gaurav Mantri's Personal Blog.

How to move Windows Azure Virtual Machines from one Subscription to another

Quite recently I was helping somebody out on MSDN forums with a question about Windows Azure Virtual Machines (IaaS). One thing that came up on that thread is how would one move their VMs from one subscription to another. There could be many reasons as to why one would want to do this. One possible scenario is that you started trying these features out in a subscription which was tied to your personal account and now you want to move that to a subscription associated with your official account. Another reason could be that you wish to move VMs from one data center to another (e.g. EU to US). I found one way of doing so which I am about to describe in this post. To be honest, it is rather a very convoluted process. If you think of better ways to accomplish this or if you’re doing it some other way, please let me know by providing your comments.

How it is accomplished?

Since the Windows Azure Virtual Machines are stored as page blobs in blob storage, mostly we’ll rely on the new asynchronous copy blob functionality to copy the blobs storing the virtual machines and data from storage account in 1st subscription (Source) to another storage account in 2nd subscription (Target). Then we’ll add these as disks and create VMs using those in the target subscription.

Again, I don’t really use VMs that much so I created a bunch of VMs using Windows Azure Platform Training Kit exercises. The one I followed is “Introduction To Windows Azure Virtual Machines” Hands On Lab. You can download the kit from here:

Once I completed the exercise, this is how things look on the portal for me. Essentially I have 2 VMs – One for the web server, one for the SQL Server and 4 Disks – 2 for VMs and 2 for SQL Server Data and Logs:



If I explore my Blob Storage, I will see 4 page blobs in “vhds” blob container. For obvious reasons, I used Cloud Storage Studio Smile


When I run my application, this is what I see in the browser.


Now let’s try and move this application to another subscription.


I followed the steps below to move my VMs from one subscription to another.

Step 1 – Copy Blobs

First we’ll copy these blobs into a storage account in the target subscription. To do so, we can make use of Asynchronous Copy Blob functionality. You can read more about this functionality on Windows Azure Storage Team Blog here: I have also written a blog post with code sample to copy an object from Amazon S3 to Windows Azure Blob Storage. You can read that post here: (You can download the source code of the Visual Studio project from here). All you have to do is provide appropriate values for various variables there. For “amazonObjectUrl” variable, you would need to provide the URL for the blobs. Richard Conway from ElastaCloud has also written a blog post about copying blobs across storage accounts which you can read here: When copying blobs from source to target storage account, there are a few things to remember:

  • Make sure that your target storage account is created after 7th June 2012 otherwise asynchronous copy blob operation will fail. If the target storage account is created before 7th of June 2012, you would need to first download the blobs on your computer and then upload them again as page blobs in the target storage account. You could use Cloud Storage Studio or any other storage explorer tool which supports downloading page blobs sparsely i.e. which only downloads the pages which are occupied or in other words downloads the pages containing non-zero bytes.
  • Since the blob container holding your blobs has a private ACL, for asynchronous copy to work, either you would need to make that blob container public (not recommended) or generate a signed URL using Blob Shared Access Signature with at least “Read” permission on the blobs (recommended). Again you could use Cloud Storage Studio or any other storage explorer which allows generation of signed URLs.

After the copy operation is completed, I see the same 4 page blobs in my target storage account.


Step 2 – Create Disks

Next we’ll create disks from these page blob VHDs for our IIS Server and SQL Server. To do so, on the portal, click on Virtual Machines –> DISKS –> CREATE DISK and follow the wizard.



You would need to do for all 4 page blob VHDs. For the disks which contain the operating system, you would need to specify so by checking the checkbox which reads “This VHD contains an operating system”. Once you’re done with this, you should see the new disks in the portal.


Step 3 – Create VMs and Attach Disks

Next step would be to create VMs. To do so, on the portal click on NEW –> VIRTUAL MACHINE –> FROM GALLERY


On the subsequent screen, click on MY DISKS option and select one VM.




Once the VM has been set up and in running state, I can RDP into that box and see exact same settings as that of the previous one.


In my scenario, I will do the same thing for my SQL Server VM.





Since with the SQL Server VM in the 1st subscription we attached 2 disks (to store the data) we would need to do the same here as well. To do so, select the SQL Server VM and click on ATTACH icon on the bottom and choose ATTACH DISK option there.




In my case, I needed to do this 2 times as I had 2 data disks. Once I am done with all of these, this is what I see in the portal.


I was expecting to see my website up and running on my 2nd subscription but got an error instead. I guess the reason for that being my SQL Server VM (and hence SQL Server) was brought up before I could attach the disks containing data. I rebooted the SQL Server VM and once it came back up, I accessed my site and it was live and kicking!!!


Step 4 – Clean Up

Last and final step is clean up which is essentially deleting the VM and associated blobs from the source subscription. These are large blobs and you don’t want to pay for storing the blobs in case you don’t want to use them anymore. To clean up data from the source subscription:

  • Detach the disks you attached.
  • Delete the VMs
  • Go into DISKS menu and delete those disks from there. IMPORTANT – Please note that deleting those disks from the portal doesn’t physically delete them from blob storage. This process just removes the locks (leases) from these disks so that you can delete them using any storage explorer. If you don’t need those disks anymore, please delete them to avoid storage charges.
  • Now delete all the disks using a storage explorer.


In this blog post, we saw that how we can move Windows Azure VMs across subscriptions. Obviously my scenario was rather simple and the VMs were not in a complex configuration. By and large, this was all made possible by Windows Azure team’s foresight of keeping the virtual machine’s and other VHDs as page blobs in blob storage. Also having asynchronous blob copy functionality across storage accounts helped immensely by cutting down the blob copy time significantly. In my case both storage accounts were in the same region and I was able to transfer 4 blobs totaling 70 GB (30 GB + 30 GB + 5 GB + 5 GB) in less than a minute.

I hope you have found this information useful. As I said at the start of my blog post, if there are better ways to accomplish this please feel free to share by providing comments below. If you think I have made some errors and provided some incorrect information, please feel free to correct me by providing comment. I’ll fix those issues ASAP.

Many thanks to Vitor Tomaz, Neil Mackenzie, and Maarten Balliauw for reviewing this blog post and providing valuable feedback.

Stay tuned for more Windows Azure related posts. So Long!!!

[This is the latest product I'm working on]


  1. Vitor Tomaz says:

    Hi Gaurav, nice post.
    If the user has the need to download the vhds from one account and upload to another I think that setting up one Large or Extra Large VM in the same datacenter and use it to transfer the vhds it’s a nice TIP. The bandwidth would be bigger and there are no upload bandwidth costs.

    • Hi Vitor,

      Thanks for commenting. I’m not sure if we really need extra large VMs for this purpose. Reason being the VHDs are essentially page blobs and the moment we write a page in page blob, it gets committed at that time only (i.e. we don’t have to call commit block list kind of functionality to save). Thus we could work with very small VM, fetch occupied pages from the source VHDs and then upload just those pages in the target storage account. To reduce the memory footprint, we can even break these pages into small pages (as long as the page size is multiple of 512 bytes). Ideally, I would just rely on new Asynchronous Copy Blob functionality if my target storage account is created after 7th June 2012. Saves me with all the hassles of writing code and worrying about what would happen if my transfer fails in between for whatever reason.

      What do you think?

  2. Thanks, Gaurav, for the interesting and inspiring article. I followed the procedure and managed to create a clone VM in the same region. My intention was to make a clone of US machine in Europe region, but the combobox Region/AffinityGroup/Virtual Network in Create virtual machine section did not contain anything but original region and original Affinity Group. So how to migrate an existing VM to some other region?

    • Thanks. I’m glad you found the post useful. I haven’t tried it but here’s what you could do:
      1. Create a new storage account in Europe region.
      2. Copy the VHDs from your storage account in the US to the storage account in Europe. Please note that you will be charged for data egress.
      3. Create a disk from that VHD in Europe region.
      4. Create a new VM from that disk.

      Hope this helps.

  3. Christian Strzadala says:

    I’ve done the process above and all has worked until I try and RDP into the VM in the new subscription. I can RDP into the VM in the original subscription but not the new one. I’ve tried resizing the VM and back to the original size but no luck.

    Any help on this would be great as this would allow us to create a production VM that could be copied between environment subscriptions for proper release process.

  4. Hector Perez says:

    Thanks alot Gaurav, you saved my head man!
    If someone don’t want to use the Asynchronous Copy Blob (all the code in the blog article), only use Cloud Storage Studio to accomplish the blob copy: connect to both storage accounts, select the blob’s to copy (in the blob container source) and click “Copy Blobs” button (to blob container target), very easy.
    Thanks again.

  5. tzvika weisman says:

    We were using customer trial version for a while but after 3 week the machine disappear and they couldn’t access to their web site.
    Hi Gaurav,
    Maybe you can help us with the below issues.
    We already understand by the Azrue forums that because of Increased use the machine went down.
    Customer already used AZURE subscription license for other project and we want to move this virtual machine ( from the trial version) to their AZURE subscription EA.
    We already succeed today to create new subscription in the Azure portal but we still don’t understand –
    1. How to migrate the virtual machine from the trail version?
    2. After the migration how to associate the new machine to the specific new subscription?

    • Can you see if you still have the VHD file in your old subscription? Normally you would find the Virtual Machine VHDs in the “vhds” blob container. If the VHD is still there, you could just copy the VHD to the new subscription using the instructions outlined in the post. You could also use Cloud Storage Studio or Azure Management Studio to copy the VHDs. Once the VHD is copied, you could just create a new VM using this VHD in your new subscription.

      Let me know if it helps. If you need more help, ping me offline by sending me an email at Gaurav @


  6. If you need to upload or download large VHDs files you can also use the Blob Transfer Utility.
    It’s a tool to handle thousands of blob transfers in a effective way.

    Binaries and source code, here:

  7. Hi there,

    I’ve got a tool to simplify a task. It captures a VHD from your server, uploads it to Azure and creates a VM in any region or affinity group, subscription you like.


    It’s in a beta development stage, so it’s free to use.

    Thanks in advance for giving it a try!

  8. Paul T. Lambert says:

    I have a SQL Server VM that has both a local C: disk and one of the new “temporary storage” SSDs as the D: disk. I would assume there’s no way to move that VM into a different subscription, since the SSD is local hardware and not in blob storage. Would that be correct?

  9. You can use DC Migration Tool, an open source tool to copy azure resources from one subscription to other subscription across data centers as well.

    Azure Data Center Migration Tool Blog

  10. Milind Patil says:

    The Azure Data Center Migration Solution (ADCMS) is designed to address common migration scenarios, such as moving to a closer data center with lower latency; deploying the same solution configuration to multiple data centers; or even moving between subscriptions, such as from an MSDN test account to a full production deployment.
    Azure Data Center Migration Tool Blog…/persistent-systems-releases-azure-data-center-migration-solution (

  11. Hi Thanks for the post. It is really useful. I am facing the same issue. But my doubt is, can we merge the azure credits from one to another? In my case, few of my services are stopped because the credits are over, but I have few credits in other account. So is it possible to transfer the credits? So that my Virtual machines and other services can be run again? Please reply. Thanks in advance.