Friday, August 26, 2016

ASM to ARM Migration

Migration from ASM to ARM

When Microsoft Azure was released it came with a deployment model named Azure Service Management (ASM). Since that time Microsoft has obviously looked at their competitors and decided to introduce a new deployment model named Azure Resource Manager (ARM). Great new deployment model but services deployed in ASM and ARM are not compatible with each other. After a long wait Microsoft has finally released some migration tools to migrate services from ASM to ARM. This article describes the process of migrating resources from the classic deployment model ASM to ARM and more specifically that of an environment that contains ExpressRoute, Virtual Network and virtual machines. My findings are based on an actual production scenario. I ran into a few issues in the process and hope you can use this article to plan your migration.

Some additional information in regards to the differences between the two models can be found here.

The migration from ASM to ARM is three steps process. You first run the prepare command which will "prepare" your ASM resources for the migration. Once you have prepared them you can Validate them. Once Validated you can Commit or Abort.

ASM to ARM Process
Handy to know:
  • ExpressRoute migrations are not supported as part of the virtual network migration. You must disconnected the ExpressRoute prior to the migration.
  • The migration process is considered to have no impact. The caveat here is around the virtual network. You cannot have a gateway, this must be removed prior to the migration, else the commit will fail. 
  • The migration "prepare" locks out classic operations. So once in this mode you cannot make changes to your classic resources. This is important as it means you cannot delete gateway, or the ExpressRoute link once the prepare command is run.
  • Virtual machines that are placed in one cloud services are migrated into availability sets in ARM. This might not necessarily be what you want. So be aware and remove if necessary.
  • Virtual machines that are placed in one cloud services are given a shared public IP and load balancer in ARM. Again this might not necessarily be what you want. So be aware and remove if necessary.
  • Network Security Groups are migrated across, but the classic objects are left behind. Delete them after the migration process.
  • Storage Accounts are migrated into a resource group that matches the name of the resource group. Not necessarily what you want, so move the storage accounts into the appropriate resource group after the migration.
  • ExpressRoute "connection" and "virtual network gateway" cannot be moved into a different resource group. So make sure you place them in the correct resource group.

The migration process

Prepare yourself

1. Map out the environment. To get make sure you're not forgetting about anything map out the environment that you are planning to migrate. In my case I had the following services to consider. A single subscription with the following services that would be affected by the migration.
  • ExpressRoute classic (Private, Public and Microsoft Peer)
  • 1x Virtual Network classic
  • 3x Cloud Services classic
  • 3x Storage Accounts classic
  • 5x Azure virtual machine classic
  • Network Security Groups bound to subnets
2. Sort out your backups. Make sure you have backups of the configuration of all your services. Not only backups of the virtual machines, but more importantly export the configurations. Below a short description of how to export the config of what services.

ExpressRoute - Not much you can do here. Make sure you have the service key.
Virtual network - connect through the portal and export the virtual network configuration. 
Azure Virtual MachineExport-AzureVM -ServiceName servicename -Name vmname -Path 'file.xml'
Network Security Group - Get-AzureNetworkSecurityGroupForSubnet -VirtualNetworkName 'virtualnetworkname' -SubnetName 'subnetname' -Detailed > 'file.txt'


3. Now that you have backups of the configuration and an understanding of your environment start looking at the execution of the migration.  

4. Step one is to migrate the ExpressRoute classic circuit to ARM. This migration does not impact the actual link and can be performed through PowerShell. This process is well documented on the following page ExpressRoute ARM Migration. Alternatively it can be done through the Azure portal. You need the servicekey name in order to migrate it across. This process takes about 5 to 10 minutes.
ExpressRoute Migration

5. Once migrated enable the "classic" operations if you desire the link to continue to operate with classic virtual networks. 

Classic operations

5. Up to this part there is no impact. Simply because we are only making changes to the presentation layer.

From this point onwards we actually start the migration of compute resources from ASM to ARM. This is where your outage will start. The process from here took my about 30 minutes. So plan for an outage of an hour.

**NOTE** I made the mistake of going ahead with the migration of the virtual network at this stage. Which won't work. You will receive the following error if you do this.

Move-AzureVirtualNetwork : BadRequest : Virtual network ******** has a gateway which must be removed before commit. The commit operation will be blocked until the gateway is removed.

6. Now you will find you cannot delete the gateway when the ExpressRoute is still connected. So delete the ExpressRoute link by running the following command.

Remove-AzureDedicatedCircuitLink -servicekey ******* -VNetName *******

6. Now delete the gateway from the Virtual Network in the portal. Once deleted we can initiate the migration.

7. Register the migration by running the following command.

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

Wait about 5 minutes and confirm that your subscription is ready by running the following command.

Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

8. Migrate the virtual network. This command will migrate the virtual network, the associated compute resources and network security groups. Run the command and wait until you receive the Operation Status Succeeded message. This can take a while, for me it took 10 minutes.

Move-AzureVirtualNetwork -Prepare -VirtualNetworkName "virtualnetworkname"

8. If you want to see the changes, logon to and you will find that new resource group will be created with cloudservicename-Migrated.

9. Review the changes that have occured, once you are happy and confident run the -Commit command. This will cutover the resources and will delete the ASM resources.

Move-AzureVirtualNetwork –Commit -VirtualNetworkName "virtualnetworkname"

10. Once move it's time to move the storage accounts across. Run the following command.

Move-AzureStorageAccount -Prepare -StorageAccountName "Storageaccountname"

11. Once the prepare has run again review the portal and you will find that they now appear in as ARM resource. If successfull run the -Commit command.

Move-AzureStorageAccount -Commit -StorageAccountName "Storageaccountname"

We're now at a point where we have migrated all the resources to ARM, it's now time to reconnect the ExpressRoute.

To connect the ExpressRoute to a ARM virtual network you need to complete a number of steps.
  • Create a virtual network gateway
  • Create a public IP address for the gateway
  • Create an ExpressRoute connection
12. Open the Azure Portal, select Create a virtual network gateway. Select the virtual network that you have migrated. Create a new Public IP. Select Gateway Type ExpressRoute and VPN type Route-based.

13. Go to ExpressRoute Circuits, select the ExpressRoute circuit, select Connections and the connection to the Gateway that we have just created.

14. Confirm that you can connect to your resources. Once you can it's time to clean up! You will find a number of resources are now located in resources group named -Migrated. You can move the resources out of those groups using the portal and make your environment look clean.

I hope this article helps you with migrating your resources to ARM. Any questions or feedback please feel free to leave a comment.


  1. you forgot to mention about moving VirtualMachines.

    1. Hi, this article specifically focused on moving from ASM to ARM from a virtual network perspective. I'll cover the move of actual virtual machines (seperate from virtual network) in another post.

      Thank you for reading.

  2. This is great. But what if you same VMs in Cloud Services and in vNETs. Do you have any ideas?

    1. Hi computingbee, thank you.

      Can you please expand on your question? i'm happy to assist but i'm not sure what you mean.

  3. Hi Ate, This is very helpful. Can you please answer to some of my questions?


    1A. Can I still use Move-AzureService or Move-AzureVirtualNetwork if my VMs are in cloud service and also connected to VNETs?
    1B. Will vNETs be put in newly created resource group if I don't migrate cloud services or will they migrated automatically when I migrate vNETs or do I need to migrate both?

    2. If I select to move only one vNET and all VMs in it. Will the routing between migrated vNET/VMs and those still managed by ASM work? i.e. inter-vNET routing between VMs managed by ARM and those managed by ASM

    3. Do I migrate everything at once if I have over 100 vNETs and Cloud Services or can we migrate one at a time?

    4. We also have an express route. Will we need to reconfigure vNETs using express route? Recently, MS enabled migration of express routes to ARM but in the interim it allows management from both ASM and ARM per these links,

  4. Hello Good Sir,

    Thanks for the information. I have finally been tasked with migrating ASM to ARM for a utility company back in Nz you built the tenant for.

    Hope all is well