Tomasz Zajda - Fotolia
Map out a smooth migration to Azure Resource Manager
As the classic Azure portal becomes outmoded, enterprises need to migrate to ARM -- but the change doesn't always come easy. Follow these steps to ensure a smooth move.
Azure Resource Manager isn't your typical software product; it's a replacement management console that both adds and obsoletes features of the legacy, or "classic," Azure management portal, called Azure Service Manager.
There are plenty of reasons to migrate to Azure Resource Manager (ARM), including a redesigned interface and its support for Availability Zones and Reserved VM Instances. But the primary reason to migrate is because Microsoft has sunsetted the classic Azure portal, which may mean no future updates or support.
However, some IT pros are still baffled by ARM and the migration process required to get there.
Migration process overview
Before you attempt to migrate to Azure Resource Manager, be sure to understand the difference between application infrastructure, known as the data plane, and management services, known as the control plane. The data plane consists of the particular application runtime environments, including VMs, database instances and storage volumes and objects, along with the data stored in each. The control plane is the collection of management tools, UIs and APIs that IT teams use to manage each application and resource.
ARM only changes the control plane, not the underlying Azure resources or instantiated services. However, since ARM also changes the internal representation of those resources, you can't just start to use the new interface. First, you must migrate data plane resources from Azure Service Manager to the new ARM paradigm.
Before you start the move, assess your environment, and compare existing resources, networks and security contexts against those available in the new portal. Azure Resource Manager supports the following infrastructure resources from the classic portal:
- VMs
- Availability Sets
- cloud services with VMs
- Virtual Networks (VNets)
- VPN gateways
- storage accounts
- ExpressRoute gateways
- network security groups (NSGs)
- Reserved IPs
- Route Tables
Cloud admins should consider the network and security context of existing VM and storage instances. For example, ARM does not support VMs that aren't in an Azure VNet. During migration, admins must either assign these VMs to an existing VNet or put them in a new VNet. For VMs already in a VNet, admins must specify during migration which network to use when there are multiple VNets available in an account.
ARM supports Azure storage accounts; however, admins must migrate VMs and networks first. Migrate unattached resources, such as storage accounts with no disks or VM data, or NSGs that aren't attached to any VMs and VNets, independently.
What's in a name?
ARM uses new names for many Azure resources, so cloud admins need to familiarize themselves with these terms. For example, cloud service names in the classic portal becomes DNS names in ARM, and VM certificates becomes certificates in Azure Key Vault in ARM.
Unsupported features and configurations in ARM include endpoint access control lists, VNet peering and VMs assigned to multiple subnets. It's possible to re-enable these configurations once the VMs and VNets are in ARM; however, admins need to remove them from the classic portal before migrating.
Major steps in the migration process
Plan for some downtime for migrated VMs. Smaller jobs, with 20 or so VMs, should take less than an hour, but large deployments with hundreds of VMs will take several hours to migrate completely.
Admins can handle the mechanics of an ARM migration via the portal itself, the Azure command-line interface, PowerShell or a tool like migAz that uses the VM API.
Microsoft recommends admins follow these four phases when they're ready to move:
- Validate a configuration to see whether a resource defined in the classic portal can be migrated, based on the limitations mentioned above.
- Simulate the migration, given the configuration specified in step one, and see if anything breaks. If a resource is unable to migrate, Azure stops the process and lists the reason why.
- Check the configuration in the ARM portal for correctness and completeness. ARM can also use a previously downloaded configuration file from the classic portal to validate against.
- Commit the migration, and start to use ARM. Alternatively, if issues arise with the migrated configuration, abort and revert to the classic portal configuration to address them.
Adequate planning and validation testing are critical; resources that migrate successfully can't be rolled back to the classic portal, and you can't abort a committed migration, even if parts of it fail.
