Home / Azure

AzureHow-toAdvanced

Transformation: move a VMware estate to Azure VMware Solution with HCX

A practical path from on-premises vSphere to Azure VMware Solution (AVS). Size the private cloud, connect it with ExpressRoute Global Reach, deploy HCX, choose vMotion or bulk migration per wave, and plan what comes after the move.

Deepak Bhardwaj3 min read

Applies toAzure VMware Solution, VMware HCX, vSphere 7/8 source environments

When AVS is the right move

AVS gives you the same vSphere, vSAN and NSX stack on dedicated Azure hosts. It suits estates that need to leave a datacentre fast, keep VMware tooling and skills, or have apps that cannot be re-platformed yet. It is a stepping stone as much as a destination: plan the next modernisation step per app from day one.

1. Assess and size

  • Export an inventory (RVTools or Azure Migrate appliance discovery): vCPU, RAM, used storage, VM count, network segments.
  • Use the Azure Migrate AVS assessment to estimate host count. Storage is often the limiting factor because vSAN capacity comes with the hosts; external storage options (Azure NetApp Files datastores, Elastic SAN) can reduce host count for storage-heavy estates.
  • Check host quota for the region before you design.
az vmware private-cloud list -o table      # needs the vmware CLI extension: az extension add -n vmware

2. Connectivity

Path Purpose
AVS ExpressRoute circuit → your Azure VNet gateway AVS to Azure services
Global Reach between your on-prem ER circuit and the AVS circuit On-premises to AVS, required for HCX
NSX-T segments Workload networks inside AVS

Plan non-overlapping address space: the AVS management block (a /22) must not overlap on-premises or Azure ranges.

3. Deploy HCX

  1. Enable the HCX add-on in the AVS private cloud.
  2. Download the HCX Connector OVA from the AVS HCX Cloud Manager and deploy it on-premises.
  3. Pair sites, create network and compute profiles, and build a service mesh.
  4. Optionally extend layer-2 networks (Network Extension) so VMs keep their IPs during the migration.

4. Choose a migration type per VM

HCX type Downtime Use for
vMotion None (live) Small numbers of critical VMs, serial
Bulk migration One reboot at switchover Most VMs, in parallel waves
Replication Assisted vMotion (RAV) None Large waves with live switchover
Cold migration VM is off Powered-off templates and VMs

Group VMs into waves by application, not by host. Migrate the dependencies of an app in the same wave so latency between tiers stays low.

Warning

Layer-2 extension adds latency for traffic hair-pinning back on-premises. Unextend networks and move the gateway to NSX in AVS as soon as a segment's VMs have all moved.

5. Cut over and verify

  • Check application health, backups (re-register in your backup tool or Azure-native backup for AVS), monitoring agents and DNS.
  • Update firewall rules for the new egress path through Azure.
  • Decommission source VMs only after a defined soak period.

6. After the move

  • Optimise: right-size VMs and remove zombies; reduce host count.
  • Integrate: use Azure Monitor, Defender for Cloud and Azure Arc for AVS VMs.
  • Modernise: move databases to Azure SQL MI or PostgreSQL Flexible Server, web tiers to App Service or AKS, freeing AVS capacity over time.

Checklist

  • Assessment and host sizing reviewed, quota approved
  • /22 management block and segments planned, no overlap
  • Global Reach and HCX service mesh healthy
  • Wave plan by application with rollback per wave
  • Backup, monitoring and DR set up on AVS before the first production wave

Related fixes