Azure Resource Mover: A Field Guide

Introduction

As organizations increasingly leverage Azure, the need to relocate resources between regions becomes a common operational requirement. Whether it's for disaster recovery planning, optimizing proximity to users, or consolidating subscriptions, moving resources across geographical boundaries within Azure has historically presented complexities. Azure Resource Mover is Microsoft's dedicated service designed to simplify this process, offering a streamlined and integrated approach to migrating Azure resources.

This field guide is aimed at cloud architects, operations engineers, and IT administrators responsible for managing and migrating Azure infrastructure. It will demystify the intricacies of cross-region resource movement, providing a practical understanding of Azure Resource Mover's capabilities, implementation steps, and best practices to ensure a successful and efficient migration.

Why this matters

The ability to seamlessly relocate Azure resources across regions offers significant strategic and operational advantages. From a business perspective, it directly contributes to business continuity by enabling robust disaster recovery strategies that involve moving critical applications to a secondary region. This improves resilience and reduces potential downtime during regional outages. Cost optimization can also be achieved by consolidating resources into regions with more favorable pricing models or by moving unused resources to colder, less expensive regions.

Technically, Azure Resource Mover addresses challenges such as data sovereignty and compliance, allowing organizations to meet regulatory requirements by ensuring data resides within specific geographic boundaries. It also enhances performance and user experience by relocating applications closer to their primary user base, thereby reducing latency. Without a structured service like Azure Resource Mover, ad-hoc migration attempts can be highly risky, lead to data loss or corruption, and consume significant manual effort, impacting productivity.

Key concepts

• Azure Resource Mover Service: The orchestration layer within Azure that facilitates the movement of resources. It helps discover, prepare, validate, and commit the move operation.
• Move collection: A logical grouping of resources that you intend to move together. This is where you define the source and target regions for your migration.
• Source region: The Azure region where the resources currently reside.
• Target region: The Azure region where the resources will be moved.
• Dependencies: Resource Mover automatically identifies direct and often indirect dependencies between resources, ensuring that all necessary components (e.g., virtual networks, storage accounts, network security groups) are moved or replicated together.
• Preparatory phase: Involves validating the move readiness of resources, deploying necessary helper resources in the target region, and transferring data for some resource types (like storage accounts).
• Commit phase: The final step where the resources are effectively moved to the target region. Post-move cleanup involves removing the original resources from the source region.
• Helper resources: Temporary resources deployed by Resource Mover in the target region to assist with the move operation, such as a staging storage account or a network interface for private endpoints. These are typically cleaned up post-migration.

Step-by-step implementation

The following steps outline the general process for moving Azure resources using Azure Resource Mover via the Azure portal.

1. Access Azure Resource Mover:

Navigate to the Azure portal (portal.azure.com), search for "Resource Mover" in the global search bar, and select "Azure Resource Mover."

1. Initiate a New Move Collection:

On the Resource Mover overview page, click on "Get started." This will guide you to create a new move collection. You'll specify the source subscription and source region, and then select the resources you wish to move.

1. Add Resources to Move:

Click "Add resources from the source region." Select the resource group(s) containing the resources you want to move. Resource Mover automatically analyzes direct dependencies. For example, when moving a Virtual Machine (VM), it will also identify its associated disks, network interfaces, and potentially the Virtual Network (VNet) and Subnets. You'll need to manually add indirectly dependent resources like Network Security Groups (NSGs) or Load Balancers if they are not automatically discovered.

1. Resolve Dependencies:

After adding resources, Resource Mover will display a list of identified dependencies. Review these carefully. If there are any missing dependencies, you will need to manually add them to the move collection. Ensure all necessary resources for your application stack are included.

1. Prepare Resources:

Select all resources in your move collection and click "Prepare." This step performs several crucial actions: Validates move readiness. Creates helper resources in the target region (e.g., Azure Site Recovery components, temporary storage accounts). Replicates data for certain resource types (e.g., storage account blobs) to the target region. For Virtual Machines, it enables replication to the target region using Azure Site Recovery.

```powershell # Example: Check the status of a move collection programmatically # Install Az.ResourceMover if you haven't already: Install-Module -Name Az.ResourceMover Connect-AzAccount -TenantId "your-tenant-id" -SubscriptionId "your-subscription-id"

$resourceGroupName = "YourMoveCollectionResourceGroup" $moveCollectionName = "YourMoveCollection"

Get-AzResourceMoverMoveCollection -ResourceGroupName $resourceGroupName -Name $moveCollectionName | Select-Object Name, SourceRegion, TargetRegion, ProvisioningState, @{Name="MoveResourcesStatus"; Expression={$_.MoveResources.ProvisioningState}} ```

1. Initiate Move (Commit):

Once all resources are in the "Prepare pending completion" state (or similar, depending on resource type), select them and click "Initiate Move." This triggers the actual move of the resources to the target region. For VMs, this involves a failover operation, which may cause downtime for the application.

1. Commit Move:

After resources are in the "Commit pending" state, select them and click "Commit Move." This finalizes the relocation.

1. Discard Source Resources (Optional but Recommended):

Once the move is confirmed successful, select the moved resources in the source region within the Resource Mover interface and click "Discard." This removes the original resources, along with any temporary helper resources, from the source region, preventing orphaned resources and incurring unnecessary costs.

Example configuration

While Resource Mover primarily operates through the Azure portal or dedicated CLI/PowerShell commands, understanding the underlying resource properties can be insightful. Below is a simplified Bicep snippet for deploying a Virtual Network, which would be a dependent resource in a VM migration scenario. The target VNet might have different address spaces or DNS servers after migration.

// This Bicep snippet demonstrates a Virtual Network definition that might be created
// in a target region, potentially after a Resource Mover operation.
// It assumes the target region's network configuration needs to be explicitly defined.

param location string = resourceGroup().location
param virtualNetworkName string
param addressPrefixes array = [
    '10.0.0.0/16'
]
param subnetName string = 'default'
param subnetAddressPrefix string = '10.0.0.0/24'

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: virtualNetworkName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: addressPrefixes
    }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: subnetAddressPrefix
        }
      }
    ]
    // Example DNS server configuration, might change during migration
    dnsServers: [
        '168.63.129.16' // Azure DNS Private Resolver (if applicable) or a custom DNS server
    ]
  }
}

output virtualNetworkId string = virtualNetwork.id
output virtualNetworkNameOutput string = virtualNetwork.name

Common pitfalls

• Overlooking indirect dependencies: While Resource Mover identifies direct links, custom route tables, DNS entries, or third-party appliance configurations might be overlooked, leading to post-migration application failures.
• Insufficient permissions: The service principal or user account performing the move often lacks the necessary contributor or owner roles across all subscriptions and resource groups involved in the move.
• Not validating target region capacity: Attempting to move large numbers of resources or specific VM sizes without checking if the target region has available quota or capacity can lead to failures during the 'Prepare' or 'Initiate Move' phases.
• Failing to test applications post-move: Assuming the migration was successful merely because Resource Mover completed the steps. Thorough application-level testing is crucial to validate functionality and performance in the new region.
• Neglecting network configuration: IP address changes, VNet peering, VPN Gateway connections, or ExpressRoute circuit mappings are frequently missed during the planning phase, breaking connectivity.
• Ignoring resource lock policies: Azure Resource Locks (Delete or ReadOnly) on resources or their containing resource groups will prevent Resource Mover from performing operations. These must be removed or excluded.

Best practices

• Plan and scope meticulously: Before initiating any move, identify all interdependent resources related to your application. Utilize the Azure Resource Graph to map out comprehensive dependencies, far beyond what the portal surface might initially show. Align with the Cloud Adoption Framework's strategy and plan methodologies for a structured approach.
• Perform a dry run with non-production environments: Always test the entire migration process with development or staging environments first. This helps identify unforeseen issues and refine your runbook.
• Ensure adequate role-based access control (RBAC): Grant the minimum necessary permissions for Resource Mover and the executing identity in both source and target subscriptions. Follow the Zero Trust principle of least privilege.
• Validate target region readiness: Verify that the target region supports all required resource types, SKUs, and has sufficient quota. Pre-provision dependent network resources (e.g., VNets, subnets) in the target region where possible, or allow Resource Mover to create them as part of the preparation.
• Automate pre- and post-move tasks: Leverage Azure Automation, PowerShell, or Azure CLI scripts to handle tasks like updating DNS records, reconfiguring application settings, or recreating services not directly supported by Resource Mover.
• Implement comprehensive monitoring and alerting: During the move, closely monitor the status of resources in Resource Mover and leverage Azure Monitor for logs and metric alerts to quickly detect and respond to any issues. Post-move, ensure application performance and health are within acceptable baselines as per the Azure Well-Architected Framework's reliability pillar.

Further reading

• About Azure Resource Mover: learn.microsoft.com/azure/resource-mover/overview
• Move Azure resources to another region: learn.microsoft.com/azure/resource-mover/move-overview
• Prerequisites for moving resources across regions: learn.microsoft.com/azure/resource-mover/check-prerequisites
• Move Azure VM to another region: learn.microsoft.com/azure/resource-mover/move-virtual-machines
• Troubleshoot Azure Resource Mover issues: learn.microsoft.com/azure/resource-mover/troubleshoot