Learning how to migrate an Azure VM from one subscription to another was tricky.

After fiddling with this for some time, I finally got the steps required in order to migrate a virtual machine from one account to another. As a web developer, I enjoy solving complicated problems. Hopefully what I learned will help you in your .NET web development efforts.

First of, the machine I used was a Linux machine in Windows Azure that I used for testing and needed to be moved to production on another subscription. It is possible you don't need to follow these exact steps anymore (Azure may have updated infrastructure to support moving VHD files without detaching them from disks/vm) but it is really not worth risking it.

Preqequisites: Red Gate Cloud Sync Free Trial is good for 30 days and then it is about 10 dollars for 31 uses a month. Totally worth it! This is a great tool for backing up Azure storage to an offsite location and SQL as well. You can use other web tools or the REST API to copy the VHD blob, but they may require you to download the blob and then re-upload. Make sure your tool doesn't do that. I decided paying $10 was not worth the time to write code or mess around with other tools.

Most often, we encounter error messages and wrong steps in Azure web development in order to get to the right steps. I’ll tell you what didn’t work first, so you can learn from my experience.

Wrong Step 1: I first thought I could just "Turn Off" the VM in the Shutdown (Allocated) state; so if anything didn't work on the other end, I could just turn the machine on again. This ended up being not true for me. After turning off the VM via SSH "sudo poweroff," the machine shutdown and kept its external IP allocated. I copied the VHD using the Red-Gate sync; and once it appeared in the new subscription, I tried to create a new Disk from it.

After trying this, I got an error saying "Blob is invalid." The MD5 checksums were the same when I looked at the blobs in the Azure portal, so I wasn't sure what the problem could have been. I decided I needed to try and see if the VHD in the source account could be used to create a disk. I tried this and got an error saying "Blob has a lease on an existing resource."

I couldn't tell if there was an issue with the VHD or not. I had to stop the source VM completely and allow the network resources be de-allocated. This wasn't ideal, but it was the only way to try and create a new disk with it. Once I stopped the VM completely, I then tried to detach the disk.

Wrong Step 2: I then tried to create a new disk on the source account again and got the same error. I could not detach the OS disk without deleting the virtual machine. Scary, but OK. I deleted the virtual machine and chose to "keep the attached disks," trusting I could always re-attach the disk and it would run fine again.

Once detached, I tried to create a new disk with the backing VHD of the other VM's disk, and this still did not work. I got an error saying the VHD was still leased to another resource. So, I went to the Disks sub menu under the Virtual Machine and decided I would then remove the disk and hopefully at that point all active leases on this VHD would be removed.

After performing this step and making sure the VHD was still retained in blob storage I tried to create a new disk using that VHD. I made sure to indicate the VHD was an OS VHD and chose Linux for it. It worked! The new disk was created on the source account. This let me know that the VHD was a valid blob file and perhaps there was some final information being written to the VHD which made it re-usable.

Wrong Step 3: After removing the new test disk I made on the source account, I then ran the Red-gate cloud sync again. Once complete I tried to create a disk again from it on the target subscription. It failed again with the "Blob is invalid" error. Why would it work on my source subscription but not my target now? I did some digging and found a blog post saying that if you copied the VHD blob while it was still attached to a disk/vm then the destination blob would not work right. I still have no clue why...but I thought I would try deleting the copied blob and syncing again.

After the wrong steps, I discovered the right ones. That tends to be how it goes when configuring and learning azure development applications and tools.

Correct Step 1 : I copied the source blob again using the Red-Gate sync tool after it was unhooked from the VM and the Disk.

Correct Step 2 : I tried to create a disk from it once it was copied and chose that it was an OS disk and selected Linux. It worked!

Correct Step 3 : I went to the  New > Virtual Machines menu and found my new disk in the Gallery.

Correct Step 4 : I chose to create a new virtual machine and cloud service. Once the machine started up, I was able to then add SSH and the new machine was up and running in my new target subscription.

In conculsion, I feel like my trouble with migrating an Azure VM from subscription to another isn’t going to be the case for you, because my VM was a few years old. But heed the above correct steps, just in case. Ideally, you will want to be able to backup a VM and move it to a new VM whenever you want.

These types of challenges come up from time to time at our Boston-based web development firm, but we enjoy a good test from time to time! How about you - What has been your experience moving VHDs between subscriptions?