Azure: Moving Virtual Machines from Classic (ASM) to Resource Management (ARM)

In this blog post, I document my experiences and lessons learned in moving my Azure virtual machines (VM) from classic Azure Service Manager (ASM) to Azure Resource Manager (ARM) deployment model. I decided to document my experience since I encountered some bumps in the migration and thought that others could benefit from how I resolved them.


If you have been using Azure for a while, you probably have created your Azure resources using the classic Service Manager (ASM) model. An easy way to check is if you have been using the classic Azure portal to manage your Azure environment (e.g.

Microsoft released a new management model called Azure Resource Manager (ARM) which provides many new capabilities to manage, and control Azure resources. Also, there is a new management portal located at: For more information on Azure Resource Manager, see here

Microsoft released a set of tools to migrate your resources from the classic Service Management (ASM) model to the new Resource Manager (ARM) model. The documentation and process for the ASM to ARM migration can be found (here).


Migrating from ASM to ARM

I printed out the docs mentioned and began the journey of moving my virtual machines to ARM.

In Step 1 (in the docs):

  • I reviewed the planning guidance.

In Step 2 (Install the latest version of Powershell):

  • See here for more information.
  • I launched Powershell ISE on my Windows 10 machine. Be sure to launch it with Administrator credentials
  • Then, I needed to install the ARM modules from the Powershell Gallery. In the Powershell ISE, run the command:   Install-module AzureRM


(This command takes some time to download, unzip, and install the ARM Powershell module.)

  • Then, I needed to install the ASM modules from the Powershell Gallery. In the Powershell ISE, I ran the command: install-module Azure



(I got an error when I ran the command. The fix was in the error message. I re-ran the command with the -AllowClobber parameter.)


(This command ran successfully.)

In Step 3 (Set your subscription and sign up for migration):

  • As documented, I ran the Powershell commands:
    • Login-AzureRmAccount
    • Get-AzureRMSubscription | Sort SubscriptionName | Select SubscriptionName
    • Select-AzureRmSubscription –SubscriptionName “My Azure Subscription”   (I put my subscription name in)
    • Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
    • Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate


  • Then, I needed to login to the ASM environment and ran the following Powershell commands:
    • Add-AzureAccount     [Note, if you get an error here, make sure that you loaded in the ASM Powershell modules using the Install-Module Azure]
    • Get-AzureSubscription | Sort SubscriptionName | Select SubscriptionName
    • Select-AzureSubscription –SubscriptionName “My Azure Subscription”


In Step 4 (Check Azure Resource Manager Virtual Machine cores):

  • As documented, I ran the Powershell commands:
    • Get-AzureRmVMUsage -Location “West US”

In Step 5 (Run commands to migrate your IaaS resources):

  • In this step, the docs separate into two sections depending upon if your resources that you want to migrate to ARM are in a virtual network or not. I needed to move my virtual machines that are in a virtual network so I skipped to the section title, “Migrate virtual machines in a virtual network.”
  • As documented, I ran the Powershell commands:
    • $vnetName = “myVnet”     [I substituted the vnet that hosts my VM’s]
    • Move-AzureVirtualNetwork –Validate -VirtualNetworkName $vnetName


(I got the message that Validation failed. Now the trick is to figure out what failed. After searching through some Powershell guides/sites, I discovered the correct syntax and run the following command to expand the Validationmessages field to see the error messages.)

    • Move-AzureVirtualNetwork –Validate -VirtualNetworkName $vnetName | select -expandproperty validationmessages


(Now, I got a bunch of error messages for all the VM’s that I was trying to migrate. I did some searching and there is a site with a list of the common errors (here). By using this site, here is a summary of the things that I did to fix the errors:

  • I shutdown my VM’s.
  • I got a bunch of errors around Availability sets. In my environment, we had multiple availability sets for each tier of the applications. The migration tool seems to only support 1 availability set across all the VM’s. I decided to remove all the Availability Sets during migration. So, I recorded the availability sets used by the virtual machines and then went through to remove them. To do this, launch the Azure Classic portal, go to the virtual machine and then the Configure tab. Then remove the Availability Set.)
    • I re-ran the Validate commands and fixed the issues until all the errors/issues were resolved.
    • Then I ran the following command: Move-AzureVirtualNetwork –Prepare -VirtualNetworkName $vnetName


(I got the error above. I did some research and one post mentioned trying to re-run the command. So, I re-ran command and it worked!)


Now, you are ready to migrate all the resources on the vnet to the ARM model. The docs state to check the configuration and if you are ready to migrate, then move to the next step by running the following command:

  • Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName


Now, you wait. After some time, the virtual machines and resources will appear in the new portal ( The migration process will create a new resource group for each cloud service and will append “-migrated” to the name.


Since, I wanted to group all the virtual machines under one resource group. I created a new resource group and started moving all the resources into that new resource group.

After doing this, I tried to start the virtual machine and got an error. The error was focused on: KeyVaultAccessForbidden


After reading through the error message, I discovered that the virtual machine was looking for the Azure Key Vault in the resource group that was created during the migration (with the “-migrated”). I had moved the Key Vault to the new resource group that I had created with all the rest of my migrated resources.

So, I moved the Key Vault back to the resource group that it was migrated originally into. After doing this move, the virtual machine started fine!

The lesson learned is: Don’t move the migrate Key Vault into a different resource group after the migration.



This entry was posted in Azure and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s