How can I move Azure VMs from different regions to one region and connect them to one VNet?

NK Global Ventures 0 Reputation points
2026-11-02T14:43:47.6966667+00:00

Hello,

We have an existing Azure subscription with multiple Virtual Machines (VMs). Currently, some of our VMs are located in different Azure regions.

Our requirement is to have four VMs located in the same Azure region and connect them through one Virtual Network (VNet).

Before making any changes to our existing resources, we would like guidance on the following:

Can an existing Azure VM be moved directly from one Azure region to another, or does it need to be migrated or recreated?

What is the safest approach to move existing VMs while preserving applications, configurations, and data?

After all four VMs are in the same region, can they be connected to one VNet, with separate subnets if required?

What are the possible cost implications of moving or recreating the VMs?

What is the recommended Azure approach for this architecture?

We already have an active Azure subscription and would like to continue using the same subscription.

Thank you for your guidance.

Azure Virtual Machines
Azure Virtual Machines

An Azure service that is used to provision Windows and Linux virtual machines.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Marcin Policht 113.2K Reputation points MVP Volunteer Moderator
    2026-11-02T15:39:12.0366667+00:00

    Generally, an existing Azure VM cannot be moved directly as-is across Azure regions through a simple resource move operation. It must be migrated or recreated in the target region. Effectively, you cannot change a VM's region property in place. Instead, you must copy the VM's underlying disks and recreate the VM interface, NICs, and associated configuration in the target region.

    However, Microsoft provides a few options for migrating VMs while preserving data and configuration within your active subscription.

    The first one is Azure Resource Mover (https://learn.microsoft.com/en-us/azure/resource-mover/overview ) - the recommended tool for moving VMs across regions within the same tenant and subscription. It automatically discovers and maps dependencies, such as disks, Network Security Groups, public IPs, and VNets, and guides you through the Prepare, Initiate Move, and Commit workflow.

    The other is Azure Site Recovery, traditionally used for disaster recovery, which can also be used to replicate VM data continuously to a target region and perform a planned failover.

    Manual Snapshot / Disk Copy is another option. This involves taking OS and data disk snapshots, copying them to the target region, and building the VMs manually. This approach offers granular control but carries a higher risk of configuration drift or human error.

    Regarding the four VMs, as part of their migration, you can connect them to the same VNet including multiple subnets. You can attach each of the four VMs to the appropriate subnet depending on your segmentation and network security requirements.

    As far as the cost goes, moving data across Azure regions can incur standard inter-region data transfer charges depending on the volume of disk data replicated. Storing snapshots, staging disks, or running ASR replication vaults incurs temporary storage costs during the migration window.

    If you spin up duplicate target VMs before decommissioning the source VMs, you will temporarily pay for double the compute and licensing hours during the testing and cutover phase. You should also verify whether the target region has different pricing tiers or SKU availability for your VM sizes.

    Consider using Azure Resource Mover since you are staying within the same active Azure subscription. Pre-create the VNet and required subnets in the destination region. Add the four VMs and their attached managed disks and NICs into an Azure Resource Mover move collection, mapping the required dependencies.

    Perform a test move and validation phase to confirm that the VMs start successfully in the target subnets and that application services function as expected. Finally, commit the move, verify production traffic, and delete the obsolete resources in the original source regions to stop ongoing charges.

    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-11-02T14:44:51.36+00:00

    Use Azure Resource Mover to replicate and recreate each supported VM in the chosen region, mapping its target NIC to one shared VNet; this is not an in-place location change, and the standard resource move operation cannot change either a VM’s region or VNet attachment.^1^

    Create the following in the destination region:

    • One VNet with a nonoverlapping address space.
    • Separate subnets where security or routing requirements differ—for example, web, application, database, and management subnets.
    • Network Security Groups (NSGs) on subnets or NICs to enforce the required traffic rules.
    • All four target VMs and their NICs in the same subscription and region as that VNet.

    A VNet is regional, and its resources must be in that region. VMs in different subnets of the same VNet can communicate through Azure’s default system routes; subnets are not security boundaries unless NSGs or other controls are applied.^2^ ^3^

    Use availability zones or an availability set in the target region where the workload requires resilience. Consolidating all four VMs into one region reduces inter-region latency, but it also removes regional redundancy.

    Safe migration sequence

    1. Inventory and prepare

    For each VM, record:

    • OS and data disks
    • VM size and availability configuration
    • NICs, private/public IP requirements, NSGs and load balancers
    • DNS records and application dependencies
    • VM extensions, identities, RBAC assignments and monitoring configuration
    • Encryption configuration and key dependencies

    Confirm that each VM’s OS, disk, compute and networking configuration is supported by Resource Mover. Important exceptions include:

    • Temporary-disk data is not migrated.
    • VM extensions are not copied and must be installed again.
    • VM-level Azure RBAC policies are not copied.
    • Boot diagnostics must be re-enabled.
    • A VM already replicated by Site Recovery must have that replication disabled before Resource Mover preparation.^4^

    Also confirm:

    • The account has Owner access for initial Resource Mover setup.
    • The target region has sufficient VM-family and resource quota.
    • The selected VM sizes and services are available there.
    • All persistent disks are attached and initialized.
    • The VMs are running during preparation.^5^

    Take an application-consistent backup before cutover. Resource Mover provides replication and a discard option, but it should not replace application-level backup and recovery planning.

    2. Create the shared destination network

    Create the target VNet and required subnets before moving the VMs. Plan nonoverlapping address ranges if the VNet will connect to on-premises networks or other VNets.

    A VM NIC, VM and VNet must be in the same subscription and location. A NIC’s VNet cannot be changed after the NIC is created, although its subnet can be changed.^6^

    3. Add each source-region group to Resource Mover

    Because the VMs originate in different regions, configure the appropriate source-to-target combination for each source region:

    1. Azure portal → search for Azure Resource Mover.
    2. Select Get Started → Move across regions.
    3. Select the existing subscription, one source region, and the common destination region.
    4. Select the VM or VMs from that source region.
    5. Select Add dependencies and include required disks, NICs, NSGs and related supported resources.
    6. Repeat for each additional source region.^5^

    In Destination configuration, map or configure each target NIC for the shared destination VNet and intended subnet. Resource Mover supports specifying an existing target-region NIC or creating one during preparation.^4^

    4. Replicate, test and cut over

    1. Select the resources in Prepare pending state and choose Prepare.
    2. Resource Mover installs the mobility agent and periodically replicates VM data without affecting the running source VM.
    3. Resolve any dependency or validation failures.
    4. During an approved outage, select Initiate move. A target replica VM is created and the source VM is shut down; VM downtime is typically measured in minutes.
    5. Validate the target VM before committing:
      • Application and service startup
      • Private connectivity among all four VMs
      • NSG and routing behavior
      • DNS, load balancer and public endpoint configuration
      • Data consistency
      • Monitoring, backup, extensions and identity access

    At Commit move pending, choose:

    • Discard move to remove the target result and return to the pre-cutover state, or
    • Commit move to finalize the target deployment.

    After commit, the source remains available for controlled cleanup and enters Delete source pending. Delete it only after the destination has passed validation.^7^

    Cost implications

    Budget for:

    • Target-region VM, disk, IP and networking prices, which can differ by region.
    • Temporary overlap while source resources remain and target replicas/resources exist.
    • Replication and cross-region data-transfer activity.
    • Backups, snapshots and retained source disks.
    • Any changed VM sizes, disk SKUs, load balancers, public IPs or security services.
    • Ongoing charges for both copies until unused source and migration resources are removed.

    Microsoft specifically recommends checking target-region charges with the Azure Pricing Calculator and confirming destination quota before beginning.^5^

    If a VM is unsupported by Resource Mover, the fallback is to copy or snapshot its OS and data disks and recreate the VM in the destination VNet. This requires a separately planned outage and application-consistency procedure rather than a direct move.^1^

    References

    1. Azure virtual machine move and migration FAQ
    2. Azure virtual networks and subnets (cross-cloud)
    3. Virtual networks and virtual machines in Azure
    4. Support for moving Azure VMs between Azure regions
    5. Move Azure VMs across regions
    6. Create, change, or delete a network interface
    7. About the move process
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.