Migrating IaaS Resources from Classic to Azure Resource Manager: A Technical Deep Dive

As the Azure platform continues to evolve, the migration from the classic deployment model to the Azure Resource Manager deployment model has become an important part of managing your cloud infrastructure. This comprehensive guide will take you on a deep dive into the technical aspects of this migration process, helping you understand how the Azure platform translates resources between the two deployment models.

Understanding the Difference Between Data Plane and Management Plane

Before we dive into the migration process, it’s crucial to understand the distinction between the data plane and the management plane when working with infrastructure as a service (IaaS) resources.

The management/control plane refers to the calls that come into the management/control plane or the API for modifying resources, such as creating a VM, restarting a VM, or updating a virtual network. These operations manage the running resources but do not directly affect connecting to the VMs.

The data plane (application) describes the runtime of the application itself, involving interaction with instances that don’t go through the Azure API. Examples include accessing your website, pulling data from a running SQL Server instance, or using Remote Desktop Protocol (RDP) or Secure Shell (SSH) to connect to a virtual machine. These operations keep the application running across compute, networking, and storage.

The data plane remains the same between the classic deployment model and the Azure Resource Manager stack. The difference lies in the representation of the resources, which the Azure platform translates during the migration process. As a result, you’ll need to use new tools, APIs, and SDKs to manage your resources in the Resource Manager stack.

The Migration Workflow

The migration process from the classic deployment model to the Azure Resource Manager deployment model involves several key steps:

  1. Validate: The validate operation analyzes the state of the resources you want to migrate in the classic deployment model, evaluating whether they are capable of migration.
  2. Prepare: The prepare operation simulates the transformation of the IaaS resources from the classic deployment model to the Resource Manager resources, allowing you to visualize the changes.
  3. Check: In this optional step, you can use the configuration you downloaded earlier or manually check the properties and resources to validate that the metadata migration looks correct.
  4. Abort: If you encounter any issues during the migration process, you can abort the migration and revert the changes to the classic deployment model.
  5. Commit: After you’ve completed the validation, you can commit the migration, and the resources will no longer be available in the classic deployment model, only in the Resource Manager deployment model.

Throughout the migration process, it’s important to note that the operations are idempotent, meaning you can retry the prepare, abort, or commit operation if you encounter any problems, and the Azure platform will try the action again.

Resource Mappings from Classic to Resource Manager

The Azure platform translates the representation of resources from the classic deployment model to the Azure Resource Manager deployment model. Here’s a table that outlines the mappings between the two:

Classic Representation Resource Manager Representation Notes
Cloud service name (Hosted Service Name) DNS name During migration, a new resource group is created for every cloud service with the naming pattern <cloudservicename>-migrated.
Virtual machine Virtual machine VM-specific properties are migrated unchanged.
Disk resources attached to VM Implicit disks attached to VM Disks are not modeled as top-level resources in the Resource Manager deployment model.
VM extensions VM extensions All the resource extensions, except XML extensions, are migrated.
Virtual machine certificates Certificates in Azure Key Vault The migration creates a new Azure key vault per cloud service and moves the certificates into the key vault.
Availability-set property Availability-set resource Availability sets become a top-level resource as part of the migration.
Network configuration on a VM Primary network interface Network configuration on a VM is represented as the primary network interface resource.
Load-balanced endpoint set Load balancer The platform assigns a new load-balancer resource, and the load-balancing endpoint set becomes load-balancer rules.
VIP address Public IP address with DNS name The virtual IP address becomes a public IP address associated with the load balancer.
Virtual network Virtual network The virtual network is migrated, with all its properties, to the Resource Manager deployment model.

This table provides a comprehensive overview of how the classic deployment model resources are translated into their Resource Manager counterparts, helping you understand the changes and plan accordingly.

Updating Your Automation and Tooling

As part of the migration process, you’ll need to update your existing automation or tooling to ensure that it continues to work after the migration. The representation of the resources has changed, and you’ll need to use the new tools, APIs, and SDKs provided by the Azure Resource Manager deployment model.

Conclusion

Migrating your IaaS resources from the classic deployment model to the Azure Resource Manager deployment model is a crucial step in optimizing your cloud infrastructure. By understanding the technical details of this migration process, you can plan and execute the migration with confidence, taking advantage of the improved performance, security, and new features offered by the Azure Resource Manager.

For more information and additional resources, please refer to the following links: