VM migration to cloud: VMware methods, downtime, network changes and rollback

VMware migration methods for moving VMs to the cloud

VM migration to a hosted VMware platform can use one of the four methods compared here: a cold copy (OVF export and import, or a powered-off cross vCenter move), replication with a Veeam planned failover, live cross vCenter vMotion, or VMware HCX, which combines replication, vMotion and network extension. Downtime runs from none for live methods to the whole copy time for cold ones; each needs different licences, network paths and access to the provider’s platform, and one migration can mix them per wave of VMs. Where both sites run it, a planned migration in VMware Live Site Recovery, covered in our article on Live Site Recovery, is a further route; our comparison of IaaS, private cloud and hybrid covers the platform model.

Broadcom: vSphere 8.0 migration pages (16 September 2026), vSphere 8.0 cross vCenter requirements (16 September 2026), KB 344959, VCF 9.1 HCX documentation (5 October 2026); Veeam Backup & Replication 13 User Guide and Cloud Connect Guide. The Fits column is our reading.

Cross vCenter vMotion and Advanced Cross vCenter vMotion

Cross vCenter vMotion moves a running VM to a host under another vCenter Server “without any interruption in its availability”, MAC addresses included. Broadcom’s KB 344959 requires vCenter Server and ESXi 6.0 or later on both sides, time-synchronised vCenters and an Enterprise Plus licence for cross vCenter and long-distance vMotion. Both vCenters must also be in Enhanced Linked Mode, which means one Single Sign-On domain shared with the provider, unless the move runs through the vSphere APIs or PowerCLI’s Move-VM cmdlet, which allow separate domains.

Advanced Cross vCenter vMotion (XVM), available from vSphere 7.0 Update 1c, “does not depend on vCenter Enhanced Linked Mode or Hybrid Linked Mode” and imports or exports VMs across Single Sign-On domains. Per Broadcom’s requirements page in the vSphere 8.0 documentation (16 September 2026), the vCenter that starts the operation must run 7.0 Update 1c or later, powered-on VMs need vSphere Enterprise Plus and powered-off VMs only vSphere Standard, so hosts on Standard can use it as a cold method. From 7.0 Update 3 it can also clone a VM and leave the original in place.

Both variants need routed paths that the provider has to agree to. KB 344959 lists TCP 8000 between the ESXi vMotion addresses, TCP 902 between the ESXi management addresses for the disk copy and TCP 443 for the vCenters. For long distances, Broadcom’s vSphere 8.0 documentation requires a round-trip time between the hosts of “up to 150 milliseconds”, a licence that covers long-distance vMotion and the disk traffic on the provisioning TCP/IP stack. vMotion traffic is encrypted when both hosts support it (the default, Opportunistic), and encrypted VMs move across vCenters only through the vSphere APIs, with the key provider that encrypted them shared by both vCenters under the same name.

A VM’s instruction set is fixed when it powers on, and live migration needs a target host that offers the same instructions. Broadcom states that processors “must come from the same vendor class (AMD or Intel) to be vMotion compatible”, so a move between CPU vendors needs a cold or restart method.

VMware HCX migration and licensing

HCX moves VMs between an HCX Connector at the source and an HCX Cloud Manager at the destination, once the sites are paired and a service mesh is deployed. In VCF 9 it is called VCF Operations HCX; Broadcom’s VCF 9.1 FAQ of 3 September 2026 lists HCX among the components that VCF licensing covers, and vSphere Foundation does not include it, as our VVF and VCF comparison shows. As of October 2026, KB 440126 adds that “Local licensing is not required at the source site when the destination is a licensed VCF environment”: the source inherits the features through the service mesh, but may “revert to evaluation status” if its connection to the destination is lost for more than 10 minutes.

Bulk Migration replicates VMs in parallel and keeps a delta synchronisation with a two-hour RPO until the scheduled switchover, when the source VM is powered off for a final offline sync; Broadcom puts the interruption at the equivalent of a reboot and calls network extension “required for low downtime migration operations”. It needs VMware Tools and hardware version 7 or later, cannot move VMs with physical-mode RDMs or virtual NVMe controllers and does not migrate snapshots. HCX vMotion moves the running state without interruption, but serially per service mesh and with at least 150 Mbps. Replication Assisted vMotion (RAV) replicates the disks ahead and switches over with vMotion, which gives parallel waves without downtime, though concurrent switchovers still run serially per service mesh; RAV shares the NVMe limit and moves no RDMs at all. Ask the provider which types its HCX Cloud Manager has activated before you plan around RAV.

Veeam replication migration with a planned failover

Without HCX or vMotion paths, replication does the copying before the window. A Veeam replication job creates a full replica on the target host in its first run, then copies only changed blocks, and the replica stays in a ready-to-start state. Veeam describes planned failover as a manual switch to the replica with minimal interruption and names “datacenter migration” as a use; its user guide for version 13 lists an incremental run, a shutdown of the source VM, a second run with the last changes and the start of the replica, so the outage covers the shutdown, the last changes and the boot. Veeam calls failover “an intermediate step that needs to be finalized”: undo failover returns to the original VM and discards the replica’s changes, failback transfers them to the original, and permanent failover makes the replica the VM for good.

A network mapping table maps production networks to destination networks, and re-IP rules change replica addresses at failover, but Veeam’s wizard applies them to one guest operating system family only, so Linux VMs need a script. With a provider that runs Veeam Cloud Connect, replicas sit on its cloud host, where Veeam supports neither re-IP rules nor DHCP, so the VMs keep their addresses, which must be static. The Cloud Connect Guide allows permanent failover there “after full site failover”, started from a cloud failover plan. Job types and replica seeding are in our article on Veeam replication, backup copy and Cloud Connect, the sequence on the day in our guide to failover and failback steps.

OVF export and import

OVF export needs no path between the sites, only a way to move files. In the vSphere Client, Export OVF Template writes a powered-off VM as .ovf, .vmdk and .mf files; “In vSphere 6.5 and later, you cannot export OVA templates”, and the VMware OVF Tool can also deploy and export OVF templates. Encrypted VMs cannot be exported. Advanced options add the BIOS UUID, MAC addresses, boot order and PCI slot numbers, which Broadcom says “limit portability”; without them the imported VM gets neither its original MAC addresses nor its BIOS UUID. The VM is down for the whole run of export, transfer, import and checks, and at a sustained 1 Gbps, 1 TB of exported files takes more than two hours to transfer (our arithmetic).

Network: stretched layer 2 or re-IP

A VM keeps its IP address only if its subnet exists at the destination. HCX Network Extension provides that: it extends VLAN-tagged port groups of a vSphere Distributed Switch and NSX segments, and migrated VMs keep their IP and MAC addresses and “behave as if on the same L2 network” as those still at the source. The default gateway stays at the source, so traffic to other subnets crosses the link between the sites. When the last VM of a subnet has moved, you unextend the network and connect the destination segment to its gateway, which HCX leaves disconnected by default to prevent a routing conflict; VMs that used DHCP or statically assigned DNS or NTP at the source can lose those services. Without HCX, a subnet moves with its gateway in one window, or you need a layer 2 link of your own.

Re-IP gives every VM a new address at the destination. Lower the TTL of each DNS record that will change, no later than one old TTL before the window, and list firewall rules, partner allow-lists, hard-coded addresses, licence servers, monitoring and backup jobs. For licences bound to hardware identity, vMotion carries the MAC addresses with the VM state, HCX Bulk Migration keeps them when Retain MAC is selected, and an OVF export keeps them only with advanced options.

Hybrid is a standard scenario on our EU cloud: some systems stay with you, some move, with replication between the sites. Send us your VM list with the subnets each VM uses and the addresses that must not change.

Migration order by dependency

An application server moved without its database sends every query across the link between the sites, so waves follow dependencies.

1. List every VM with its owner, disk size, hardware version, disk controllers, encryption, CPU vendor, VMware Tools state, snapshots, RDMs and licences tied to a MAC address or host.
2. Map dependencies from flow records and firewall logs, and confirm them with each application owner.
3. Prepare the destination: networks or extensions, directory and DNS services reachable there, firewall rules, backup and monitoring.
4. Run a pilot wave of non-critical VMs, rollback included.
5. Move each application with its database and the services it calls often, in an agreed maintenance window, with an owner test and a fixed go or no-go time.
6. Switch external access last: public DNS, certificates, NAT rules and partner VPNs.
7. Keep whatever remains at the source until the wave is signed off.

Rollback plan for each method

Going back is simple until the destination has taken writes that must be kept; after that, the new data has to move back as well.

Broadcom TechDocs: VCF 9.1 HCX documentation (5 October 2026), HCX 9.0 user guide (25 February 2025), vSphere 8.0 migration documentation (16 September 2026). Veeam Backup & Replication 13 Quick Start Guide (25 November 2025).

A VM’s CPU features are set when it powers on, so after a power-off and power-on at newer destination hosts a vMotion back to older source hosts can fail; a per-VM EVC mode matching the source hosts keeps it possible. Because “A VMware product cannot power on a virtual machine with a virtual hardware version that is higher than what it supports”, leave the Upgrade Virtual Hardware option of HCX off until the wave is signed off.

We move systems step by step, in agreed maintenance windows, with a rollback plan. Tell us which systems you would move first and how you would test them.

What we do

Our EU cloud service hosts IaaS on the VMware vSphere platform and dedicated private clouds in Baltneta’s Tier-3 data centres in Lithuania (ISO 27001, PCI DSS); our engineering partner Vixen.UNO handles migration engineering and support. The first call is free of charge, and the paid technical assessment, its price fixed before work begins, reviews your systems and the target configuration and delivers a step-by-step migration plan. We provide test access to the platform before migration and then move the systems in agreed maintenance windows. You sign one contract with Eurokommerz and work with one project lead.

FAQ