When you are ready to migrate your VMs from ASM to ARM mode, there are several platform supported mechanisms you can leverage. They are documented here. The main things to note are:
- Network moves impact all VMs in the VNet - if you are going to move a VNet, all the VMs go with it.
- If your VNet is attached to a VPN gateway, you can move it without downtime.
- If your VNet is attached to an ExpressRoute gateway, you CANNOT move it without downtime (info current as of 10/17/16, hopefully to change soon).
This quick post will cover item number three - the only way to move is manually. This means powering off your VMs, deleting the VMs without removing the disks, using the platform migration tools to migrate the storage, then recreating the VMs in ARM mode with Attach Disk(s) options.
All of this can be / should be scripted. I'm going to make an assumption that you know how to script getting the details of an ASM VM and the details of how to create a corresponding ARM VM and focus on the storage account migration experience.
- Log in to Azure (ASM AND ARM) with the source subscription selected.
- Register your subscription (one time operation) for migration:
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
- Come back in five minutes and check to make sure you are now registered:
- Some prep steps go here: make sure your new VNets are up and running in ARM mode with whatever connectivity you require (VPN, ER, Peering, etc). Make sure you have all the details of your ASM mode VMs: Name, Instance Size, Disk Storage Location, etc. You also HAVE to do this for every VM that is in the Storage Account that we're going to move so that is your lower bounds.
- Begin executing your script:
A) Power off the VMs
B) Delete the VMs while retaining the disks
C) Wait two or three minutes for locks to release. If you move too fast, you will get an exclusive lock error, just do a loop in your script to try again/keep trying waiting 30 seconds at a time.
D) Migrate the storage step 1:
$storageAccountName = "<storage account name>" --- this can take a while. If for some reason you don't get a "Succeeded" during Prepare step, cancel it with -Abort.
Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName
Observe that there really is no change once that comes back:
E) Once you are complete with "Succeeded" in the prepare step, time to Commit. Here's what that looks like.
move-azurestorageaccount -Commit -StorageAccountName $StorageAccountName
Notice a few things:
1. The storage account is no longer visible in ASM mode.
2. The Default-... Resource group that showed your storage account in ARM mode no longer shows that storage account.
3. A new Resource Group of StorageAccount-Migrated is now in ARM and containes your migrated storage account.
- Enumerate your storage accounts in PowerShell, grabbing the migrated one and proceed with creating your VMs back in, adding them to the new VNet, matching up the sizes/location etc, and powering them up - make sure you attach your disks!
TL;DR - there are a few unofficial tools that can help you with the above and can be viewed here and here.. Of the two unofficial tools, I prefer MigAz as it can allow VMs to be moved without an outage IN SOME CASES -- read the warnings and also generates nice shiny ARM templates.