GA of Azure VM Migration from Classic to Resource Manager

Microsoft has announced the general availability of a new migration service to move your Azure virtual machines and their dependencies from Classic / Service Management / ASM / Azure V1 to the newer Azure Resource Manager / ARM / Azure V2.

Reminder

As I discussed in A Tale of Two Azures, Microsoft made significant changes to Azure when they introduced a new API for managing resources in the cloud. We can see that virtual machines that were deployed in the older ASM are based on a simpler design, probably based on a cloud service.
Microsoft released ARM to speed up deployments and expansion via templates, and all of Microsoft’s focus is on this newer version of management and deployment. In fact, Microsoft’s preferred channel for selling cloud services to the “breadth market”, Cloud Solution Provider (CSP), has no support for classic or ASM resources.
Most of Microsoft’s Azure customers will have deployed virtual machines using ASM. Microsoft wants those customers to use the newer version of Azure and the services & features that are being added & improved only in ARM. And to be honest, in my experience, deploying and owning resources in ARM is a much better experience. So those customers need a way to migrate their virtual machine workloads from Classic to Resource Manager, which is not just some simple change.
Note that Microsoft goes to great lengths to say that they are not pressuring anyone to migrate from ASM to ARM, but that they do think you should consider it to avail yourself of the benefits.

What Does the Solution Do?

The migration solution will lift an entire virtual machine deployment from ASM and move it to ARM. The storage accounts, the virtual network, and even the cloud service, including endpoints and load balancing. And the nice bit – this can be done with zero downtime!
There are a couple of things to note with networks:

• The entire network must be migrated; you cannot move it subnet by subnet.
• SM allows you to deploy virtual machines without a subnet (which I never understood!). Migrating these virtual machines will require a reboot as they are moved into a virtual network (mandatory). You must migrate a public IP before you migrate.

Migration of production systems can be scary, so there is a pre-migration verification process, called a simulation, where your virtual machine resources are managed by both Service Management and Resource Manager. The connection of the ARM API allows Azure to verify that it will be able to control every element of the network that you are migrating after the move is complete. Microsoft says that Azure will explain the reasons behind any resources that cannot be migrated.
During the simulation, the successfully connected resources stay under the control of ASM, but the ARM API are connected to the resources too. This allows you to validate your new ARM scripts and tools while they continue to be managed via the ASM API. You can stay in this simulated state for as long as you want, but remember that your configurations will remain frozen until you abort or commit.

Your systems will be in a read-only state during this phase; your data is still being saved in the machines, but you cannot make configurations changes.

Once you are happy, the classic ASM endpoint can be removed, and your migration is completed. If you abort, the ARM API is removed, and any resources that are created for the ARM migration, such as NICs or a load balancer (instead of a cloud service) are removed by Azure.

Unsupported Scenarios

Microsoft cannot migrate everything. The following resources cannot be migrated:

• Un-associated virtual hard disks
• Images of virtual machines
• Unreserved IP addresses
• Un-associated network security groups
• Endpoint ACLs
• Virtual network gateways – you’ll need to recreate your ExpressRoute or VPN configurations which might cause accessibility downtime for some customers.

The following configurations are unsupported:

• Role-based access control (RBAC): You will need to redeploy your RBAC configuration (see Resource Groups).
• Virtual machines with multiple subnets: Only machines connected to a single subnet will be migrated.
• Virtual machines without an explicit subnet: You can delete the machine.
• Alerts and Auto-Scaling: These settings will be dropped during the migration. You can reconfigure these settings afterwards.
• XML Extensions: Virtual machine extensions such as Virtual Studio Debugger, Web Deploy and Remote Debugging should be removed first.
• Cloud Services/virtual networks containing Web/Worker roles: This is not supported at this time.
• Virtual networks that contain HDInsights: This is not supported at this time.
• Virtual networks with Dynamics Lifecycle Services-managed virtual machines: This is not supported at this time.