Azure Resource Mover for cross-region movement of resources:

Business Continuity and Disaster Recovery standards of the public cloud recommend backup and restore with Azure Backup and Azure Site Recovery vaults and maintaining a paired region presence in modes such as active-passive or active-pilot. The cross-region movement of resources is talked about less from that angle, but it frequently supports ever-evolving business needs including those from mergers and acquisitions. Azure Resource Mover greatly reduces customer time and effort needed to move resources across regions by providing a built-in dependency analysis, planning, and testing that ensures the resources are prepared to move and then successfully moved to the desired region. Azure Resource Mover also provides a seamless and consistent single pane of glass experience that allows move orchestration for a range of Azure resources including virtual machines and databases. By virtue of its automation and single-click move capabilities, it reduces the time and effort needed to move resources across regions. This technique comes with the ability to rename resources and customize ip addresses in the target location that are important features to streamline and simplify the process.

Often used to take advantage of new Azure region expansions to be closer to the end-customers by reducing latency and to consolidate workloads into single regions to support merger and acquisitions, the Azure Resource Mover facilitates a wide range of resource types but does have its restrictions. It’s important to recognize the displacement involved as one resource group to another, one subscription to another or one region to another because different displacements come with different automations and as features of different resources. For example, Azure Resource Mover can move VMs and related disks but connected clusters for Microsoft.Kubernetes resource type cannot be moved across regions. Multi-region clusters are also possible with some resource types. Child resources can’t be moved independently from its parent resources. The naming convention indicates whether a resource is a child or a parent because they are prefixed with the parent resource type. For example, a Microsoft.ServiceBus/namespaces/queues resource cannot be moved independent of Microsoft.ServiceBus/namespaces resource.

Some resources can be moved with the help of their templates. This is the case with API management resources.  The resource is exported with its template. Then it is adapted to the target region and recreated as a new resource.  The same instance name is maintained if the source is deleted. Otherwise, the destination will require custom domain CNAME records to point to the new API management instance.

Databases also get a different treatment. Usually a cross-region read replica is used to move an existing server. If the service is provisioned with geo-redundant backup storage, we can use geo-restore to restore it in other regions. Another way to move resources is to clone an existing region to another region as in the case of an IoT hub. Resources like key-vaults can be created as many as one per region so they are often left out of the resource movement inventory. Public ip address configurations can be moved but these addresses cannot be retained. Finally, recovery services vaults can themselves be disabled in the originating region and recreated in the target region.