I was recently discussing Azure infrastructure services with a customer who has implemented a solution based on Azure Service Manager (ASM – also known as classic mode) but is now looking to move to Azure Resource Manager (ARM).

Moving to ARM has some significant benefits. For a start, we move to declarative, template-driven deployment (infrastructure as code). Under ASM we had programmatic infrastructure deployment where we wrote scripts to say “Dear Azure, here’s a list of everything I want you to do, in excruciating detail“ and deployment ran in serial. With ARM we say “Dear Azure, here’s what I want my environment to look like – go and make it happen” and, because Azure knows the dependencies (they are defined in the template), it can deploy resources in parallel:

• If a resource is not present, it will be created.
• If a resource is present but has a different configuration, it will be adjusted.
• If a resource is present and correctly configured, it will be used.

ASM is not deprecated, but new features are coming to ARM and they won’t be back-ported. Even Azure AD now runs under ARM (one of the last services to come across), so there really is very little reason to use ASM.

But what if you already have an ASM infrastructure – how do you move to ARM? Christos Matskas (@christosmatskas) has a great post on options for migrating Azure VMs from ASM (v1) to ARM (v2) which talks about four methods, each with its own pros and cons:

• ASM2ARM script (only one VM at a time; requires downtime)
• Azure PowerShell and/or CLI (can be scripted and can roll-back; caveats and limitations around migrating whole vNets)
• MigAz tool (comprehensive option that exports JSON templates too; some downtime required)
• Azure Site Recovery (straightforward, good management; vs. setup time and downtime to migrate)

Full details are in Christos’ post, which is a great starting point for planning Azure VM migrations.