Platform-supported migration of IaaS resources from classic to Azure Resource Manager

In this article, we describe how we're enabling migration of infrastructure as a service (IaaS) resources from the Classic to Resource Manager deployment models. You can read more about Azure Resource Manager features and benefits. We detail how to connect resources from the two deployment models that coexist in your subscription by using virtual network site-to-site gateways.

Goal for migration

Resource Manager enables deploying complex applications through templates, configures virtual machines by using VM extensions, and incorporates access management and tagging. Azure Resource Manager includes scalable, parallel deployment for virtual machines into availability sets. The new deployment model also provides lifecycle management of compute, network, and storage independently. Finally, there’s a focus on enabling security by default with the enforcement of virtual machines in a virtual network.

Almost all the features from the classic deployment model are supported for compute, network, and storage under Azure Resource Manager. To benefit from the new capabilities in Azure Resource Manager, you can migrate existing deployments from the Classic deployment model.

Supported resources for migration

These classic IaaS resources are supported during migration

  • Virtual Machines
  • Availability Sets
  • Cloud Services
  • Storage Accounts
  • Virtual Networks
  • VPN Gateways
  • Express Route Gateways (in the same subscription as Virtual Network only)
  • Network Security Groups
  • Route Tables
  • Reserved IPs

Supported scopes of migration

There are 4 different ways to complete migration of compute, network, and storage resources. These are

  • Migration of virtual machines (NOT in a virtual network)
  • Migration of virtual machines (in a virtual network)
  • Storage accounts migration
  • Unattached resources (Network Security Groups, Route Tables & Reserved IPs)

Migration of virtual machines (NOT in a virtual network)

In the Resource Manager deployment model, security is enforced for your applications by default. All VMs need to be in a virtual network in the Resource Manager model. The Azure platform restarts (Stop, Deallocate, and Start) the VMs as part of the migration. You have two options for the virtual networks that the Virtual Machines will be migrated to:

  • You can request the platform to create a new virtual network and migrate the virtual machine into the new virtual network.
  • You can migrate the virtual machine into an existing virtual network in Resource Manager.

Note

In this migration scope, both the management-plane operations and the data-plane operations may not be allowed for a period of time during the migration.

Migration of virtual machines (in a virtual network)

For most VM configurations, only the metadata is migrating between the Classic and Resource Manager deployment models. The underlying VMs are running on the same hardware, in the same network, and with the same storage. The management-plane operations may not be allowed for a certain period of time during the migration. However, the data plane continues to work. That is, your applications running on top of VMs (classic) do not incur downtime during the migration.

The following configurations are not currently supported. If support is added in the future, some VMs in this configuration might incur downtime (go through stop, deallocate, and restart VM operations).

  • You have more than one availability set in a single cloud service.
  • You have one or more availability sets and VMs that are not in an availability set in a single cloud service.

Note

In this migration scope, the management plane may not be allowed for a period of time during the migration. For certain configurations as described earlier, data-plane downtime occurs.

Storage accounts migration

To allow seamless migration, you can deploy Resource Manager VMs in a classic storage account. With this capability, compute and network resources can and should be migrated independently of storage accounts. Once you migrate over your Virtual Machines and Virtual Network, you need to migrate over your storage accounts to complete the migration process.

Note

The Resource Manager deployment model doesn't have the concept of Classic images and disks. When the storage account is migrated, Classic images and disks are not visible in the Resource Manager stack but the backing VHDs remain in the storage account.

Unattached resources (Network Security Groups, Route Tables & Reserved IPs)

Network Security Groups, Route Tables & Reserved IPs that are not attached to any Virtual Machines and Virtual Networks can be migrated independently.


Unsupported features and configurations

We do not currently support some features and configurations. The following sections describe our recommendations around them.

Unsupported features

The following features are not currently supported. You can optionally remove these settings, migrate the VMs, and then re-enable the settings in the Resource Manager deployment model.

Resource provider Feature Recommendation
Compute Unassociated virtual machine disks. The VHD blobs behind these disks will get migrated when the Storage Account is migrated
Compute Virtual machine images. The VHD blobs behind these disks will get migrated when the Storage Account is migrated
Network Endpoint ACLs. Remove Endpoint ACLs and retry migration.
Network Application Gateway Remove the Application Gateway before beginning migration and then recreate the Application Gateway once migration is complete.
Network Virtual networks using VNet Peering. Migrate Virtual Network to Resource Manager, then peer. Learn more about VNet Peering.

Unsupported configurations

The following configurations are not currently supported.

Service Configuration Recommendation
Resource Manager Role Based Access Control (RBAC) for classic resources Because the URI of the resources is modified after migration, it is recommended that you plan the RBAC policy updates that need to happen after migration.
Compute Multiple subnets associated with a VM Update the subnet configuration to reference only subnets.
Compute Virtual machines that belong to a virtual network but don't have an explicit subnet assigned You can optionally delete the VM.
Compute Virtual machines that have alerts, Autoscale policies The migration goes through and these settings are dropped. It is highly recommended that you evaluate your environment before you do the migration. Alternatively, you can reconfigure the alert settings after migration is complete.
Compute XML VM extensions (BGInfo 1.*, Visual Studio Debugger, Web Deploy, and Remote Debugging) This is not supported. It is recommended that you remove these extensions from the virtual machine to continue migration or they will be dropped automatically during the migration process.
Compute Boot diagnostics with Premium storage Disable Boot Diagnostics feature for the VMs before continuing with migration. You can re-enable boot diagnostics in the Resource Manager stack after the migration is complete. Additionally, blobs that are being used for screenshot and serial logs should be deleted so you are no longer charged for those blobs.
Compute Cloud services that contain web/worker roles This is currently not supported.
Compute Cloud services that contain more than one availability set or multiple availability sets. This is currently not supported. Please move the Virtual Machines to the same availability set before migrating.
Compute VM with Azure Security Center extension Azure Security Center automatically installs extensions on your Virtual Machines to monitor their security and raise alerts. These extensions usually get installed automatically if the Azure Security Center policy is enabled on the subscription. To migrate the Virtual Machines, please disable the security center policy on the subscription which will remove the Security Center monitoring extension from the Virtual Machines.
Compute VM with backup or snapshot extension These extensions are installed on a Virtual Machine configured with the Azure Backup service. To migrate these Virtual Machines, follow the guidance here.
Network Virtual networks that contain virtual machines and web/worker roles This is currently not supported. Please move the Web/Worker roles to their own Virtual Network before migrating. Once the classic Virtual Network is migrated, the migrated Azure Resource Manager Virtual Network can be peered with the classic Virtual Network to achieve similar configuration as before.
Network Classic Express Route circuits This is currently not supported. These circuits need to be migrated to Azure Resource Manager before beginning IaaS migration. To learn more about this see Moving ExpressRoute circuits from the classic to the Resource Manager deployment model.
Azure App Service Virtual networks that contain App Service environments This is currently not supported.
Azure HDInsight Virtual networks that contain HDInsight services This is currently not supported.
Microsoft Dynamics Lifecycle Services Virtual networks that contain virtual machines that are managed by Dynamics Lifecycle Services This is currently not supported.
Azure AD Domain Services Virtual networks that contain Azure AD Domain services This is currently not supported.
Azure RemoteApp Virtual networks that contain Azure RemoteApp deployments This is currently not supported.
Azure API Management Virtual networks that contain Azure API Management deployments This is currently not supported. To migrate the IaaS VNET, please change the VNET of the API Management deployment which is a no downtime operation.

Next steps