If you still have any Azure classic Resources running under your Subscription, you will have to migrate it to Resource Manager module at some point, as there is many features in Azure that doesn’t Support the Classic module.

For example, if you would like to move your Resources to another Subscription, you will not be able to do that for the classic resources, so you will have to migrate the classic resources to Resource Manager, then move them to another subscription as needed.

Its highly recommended to review the below Microsoft articles before starting the Migration process:

·        Technical deep dive on platform-supported migration from classic to Azure Resource Manager

·        Translation of the classic deployment model to Resource Manager resources

·        Planning for migration of IaaS resources from classic to Azure Resource Manager

Azure now offer an easy and simple way of migrating your Classic resources to Resource Manager using the Portal. However, many Administrators would prefer to use PowerShell as a better and more powerful way for migration. Therefore, we are providing you this article to guide you through the migration.

First of all, you’ve to review the below Azure documentation to review the supported resources that can be migrated, and the unsupported resources/features, that can’t be migrated from Classic to Resource Manager:

·        Supported resources for migration

·        Unsupported features and configurations

Few important points to keep in mind before the Migration:

·        If you would like to keep the same public IP addresses for your VMs, you need to make sure that all your Public IP address that is associated with any of the VMs are set to Static, using Reserved IP resources, that’s if you would like to keep the same Public IP after migration.

·        The Endpoint ACLs from Classic deployment doesn’t support the Migration, so you will have to remove it prior to the migration.

·        To make sure that your VMs/Applications will be up and running after the migration, you can replace the Endpoints with network security groups prior to the Migration.

·        There should be no down time regarding the VM accessibility, and the applications are running on the VMs. However, all the management operations will be blocked during the Migration and will be allowed again after committing the migration.

·        In this article, we will be taking about migrating Classic Virtual Machines which are in a Virtual Network.

ASM/Classic to ARM Migration PowerShell:

We will be using the Azure ARM PowerShell Module for performing the migration.

Migration Prerequisites:

·        Make sure that you’ve the AzureRM, and the Azure Classic PowerShell Modules are installed on your PowerShell.

·        Register the Migration Resource Provider:

Login-AzureRmAccount

Select-AzureRmSubscription -SubscriptionId "<Subscription ID>"
Register-AzureRmProviderFeature -FeatureName ClassicInfrastructureMigrate -ProviderNamespace Microsoft.ClassicInfrastructureMigrate   #(the Registration State should be "Registering.)

1. Wait five minutes, and confirm that the registration was completed using the below command:

Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

·        Validate that there are enough available resources (i.e. CPU Cores, Public IP & Reserved IP Addresses, and etc.) for the number of Virtual Machines being migrated within your region:

Get-AzureRmVMUsage -Location "geo location"

Migration Steps Explained:

Any resource that will be migrated from Classic to Resource Manager, will go through the below steps:

a.  Validate:

The Validation step will check the eligibility of the Classic resource to be migrated to ARM.

b.  Prepare:

This will create a new ARM resource as a replica of the Original Classic resource, with all the associated resources as well.

The original Classic resource, and associated resources will remain existing, and will be functioning as usual.

At this specific step, the Classic resources, and the migrated ARM ones, will be Locked for any management operations.

**** this step is designed to create the ARM resources without deleting the Original Classic ones, so you can test the functionality of your environment over ARM, without risking to loose the original Classic resources.

After testing and validating your environment functionality over ARM platform, you have the decision either to commit the migration to stay on ARM and delete the Classic resources. Or to Abort to delete the ARM resources, and go back to the Classic resources.

c.  Commit:

If you are all good with the new ARM resources, then you have to commit the Migration, which will automatically delete the original Classic resources, and will unlock the management operations on the ARM ones.

d.  Abort operation:

If you faced some issues over ARM platform, you can trigger the Abort step to cancel the migration, delete the created ARM resources and unlock the management operations on the Original Classic resources.

Migrate the Classic VNET with the associated VMs:

we need to login to your subscription through PowerShell using the Classic Module:

Add-AzureAccount

Select-AzureSubscription -SubscriptionId "<SubscriptionId>" -Current
  1. Validate:
Move-AzureVirtualNetwork -Validate -VirtualNetworkName "vnetname"-Debug

Check for the validation messages from the output and clear them until it succeeds without error.

2.   Prepare:

Move-AzureVirtualNetwork -Prepare -VirtualNetworkName "vnetname"-Debug

After the Prepare has succeeded, check to ensure all Virtual Machines have been created on ARM side.

Any errors, the abort should be performed so that the errors can be resolved and then rerun the Validate and Prepare.

3.   Commit:

Move-AzureVirtualNetwork -Commit -VirtualNetworkName "vnetname"-Debug
  • Abort operation (if Prepare fails):
Move-AzureVirtualNetwork -abort -virtualNetworkName "Vnetname”

Storage Account Migration:

Before moving the storage account, please ensure there are no other Classic VMs which haven't been migrated yet, nor are there any VM images or unassociated VHD disks.

1.      Validate operation:

Move-AzureStorageAccount -Validate -StorageAccountName "saname" -Debug

2.      Prepare operation:

Move-AzureStorageAccount -Prepare -StorageAccountName "saname" -Debug

3.      Commit operation:

Move-AzureStorageAccount -Commit -StorageAccountName "saname" -Debug

4.      Abort operation (if Prepare fails):

Move-AzureStorageAccount -Abort -StorageAccountName "SAName"

Migrate Reserved Virtual IP address (unassociated):

1.      Validate operation:

Move-AzureReservedIP -Validate -ReservedIPName "VIPName" -Debug

2.      Prepare operation:

Move-AzureReservedIP -Prepare -ReservedIPName "VIPName" -Debug

3.      Commit operation:

Move-AzureReservedIP -Commit -ReservedIPName "VIPName" -Debug

4.      Abort operation (if Prepare fails):

Move-AzureReservedIP -Abort -ReservedIPName "VIPName" -Debug

One last important note, the process of migrating the resources from ASM to ARM, might create new Key Vault, and had secrets associated with the Migrated VMs.

The new Vault/vaults will not cause any issues when managing or accessing your VMs, however if you would like to move the migrated to resources it will cause a failure of the move validation.

So you need to remove these Secrets using the below command only if you don’t have any other Key vaults in place before the migration:

$vm = Get-AzureRmVM -ResourceGroupName "MyRG" -Name "MyVM"
Remove-AzureRmVMSecret -VM $vm
Update-AzureRmVM -ResourceGroupName "MyRG" -VM $vm 

We hope that the above article help you with Migrating your Azure VMs within VNET from Classic (ASM) to Resource Manager (ARM).