Azure Deployment Models And How To Migrate From ASM to ARM

This is a post about the two deployment models currently available in Azure, Service Management (ASM) and Resource Manager (ARM). And how to migrate from one to the other if necessary.

About the Azure Service Management deployment model

The ASM model, also known as version 1 and Classic mode, started out as a web interface and a backend API for the PaaS services Azure opened with at launch.

Features

1. ASM deployments are based on an XML schema.
2. ASM operations are based at the cloud service level.
3. Cloud services are the logical containers for IaaS VMs and PaaS services.
4. ASM is managed through the CLI, old and new portals (features) and PowerShell.

About the Resource Manager deployment model

The ARM model consists of a new web interface and API for resource management in Azure which came out of preview in 2016 and introduced several new features.

Features

1. ARM deployments are based on a JSON schema.
2. Templates, which can be imported and exported, define deployments.
3. RBAC support.
4. Resources can be tagged for logical access and grouping.
5. Resource groups are the logical containers for all resources.
6. ARM is managed through PowerShell (PS), the CLI and new portal only.

Why use Service Management mode?

1. Support for all features that are not exclusive to ARM mode.
2. No new features will be made available in this mode.
3. Cannot process operations in parallel (.e.g. vm start, vm create, etc).
4. ASM needs a VPN or ExpressRoute connection to communicate with ARM.
5. In Classic mode templates cannot be used to configure resources.

Users should therefore only be using service management mode if they have legacy environments to manage which include features exclusive to it.

Why use Resource Manager mode?

1. Support for all features that are not exclusive to ASM mode.
2. Can process multiple operations in parallel.
3. JSON templates are a practical way of managing resources.
4. RBAC, resource groups and tags!

Resource manager mode is the recommended deployment model for all Azure environments going forward.

Means of migration

The following tools and software are available to help with migrating environments.

ASM2ARM custom PowerShell script module.
Platform supported migrations using PowerShell or the Azure CLI.
The MigAz tool.
Azure Site Recovery.

About ASM2ARM

ASM2ARM is a custom PowerShell script module for migrating a single Virtual Machine from Azure Service Management to Resource Manager stack which makes available two new cmdlets.

Cmdlets: Add-AzureSMVmToRM & New-AzureSmToRMDeployment

Code samples:

[code language=”powershell”]$vm = Get-AzureVm -ServiceName acloudservice -Name atestvm
Add-AzureSMVmToRM -VM $vm -ResourceGroupName aresourcegroupname -DiskAction CopyDisks -OutputFileFolder D:\myarmtemplates -AppendTimeStampForFiles -Deploy[/code]

Using the service name and VM name parameters directly.

[code language=”powershell”]Add-AzureSMVmToRM -ServiceName acloudservice -Name atestvm -ResourceGroupName aresourcegroupname -DiskAction CopyDisks -OutputFileFolder D:\myarmtemplates -AppendTimeStampForFiles -Deploy[/code]

Features

1. Copy the VM’s disks to an ARM storage account or create a new one.
2. Create a destination vNet and subnet for migrated VMs.
3. Create ARM JSON templates and PS script for deployment of resources.
4. Create an availability set if one exists at source.
5. Create a public IP if the VM is open to the internet.
6. Create network security groups for the source VMs public endpoints.

Limitations

1. Cannot migrate running VMs.
2. Cannot migrate multiple VMs.
3. Cannot migrate a whole ASM network
4. Cannot create load balanced VMs.

For more information: https://github.com/fullscale180/asm2arm

About platform supported migrations using PowerShell

Consists of standard PowerShell cmdlets from Microsoft for migrating resources to ARM.

Features

1. Migration of virtual machines not in a virtual network (disruptive!).
2. Migration of virtual machines in a virtual network (non-disruptive!).
3. Storage accounts are cross compatible but can also be migrated.

Limitations

1. More than one availability set in a single cloud service.
2. One or more availability sets.
3. VMs not in an availability set in a single cloud service.

About platform supported migrations using the Azure CLI

Consists of standard Azure CLI commands from Microsoft for migrating resources to ARM.

Features & Limitations

See above.

A video on the subject of platform supported migrations using PowerShell or the CLI.

About MigAz

MigAz comes with an executable which outputs reference JSON files and makes available a Powershell script capable of migrating ASM resources and blob files to ARM mode environments.

Features

1. MigAz exports JSON templates from REST API calls for migration.
2. New resources are created in and disk blobs copied to their destination, all original resources left intact.
3. Exported JSON can (and should) be reviewed and customized before use.
4. Export creates all new resources in a single resource group.
5. Supports using any subscription target, same or different.
6. With JSON being at the core of ARM, templates can be used for DevOPs.
7. Can be used to clone existing environments or create new ones for testing.

About Azure Site Recovery (ASR)

ASR is a backup, continuity and recovery solution set which can also be used for migrating resources to ARM.

Features

1. Cold backup and replication of both on and off premise virtual machines.
2. Cross compatible between ASM and ARM deployment models.
3. ASM virtual machines can be restored into ARM environments.

Pros and cons

ASM2ARM: Requires downtime but can be scripted which has potential however this approach only allows for the migration of one VM at a time which is a sizable limitation.

Azure PowerShell and CLI: This approach is well rounded. It can be scripted and allows for rollbacks. Supported migration scenarios include some caveats however and you cannot migrate a whole vNet into an existing network.

MigAz Tool: Exports JSON of ASM resources for customization and uses a PowerShell script for deployment to ARM. Downtime is required going to the same address space or cutting over to new services but this is easily your best and most comprehensive option at this time.

Site Recovery: Possibly the easiest way of migrating resources and managing the overall process but requires a lot of work to set up. Downtime is required in all cases.