Escaping VMware: Migrating Your vSphere Estate in 2026
The licensing changes did what a decade of cloud evangelism couldn’t: they put a hard number on staying put. If your VMware renewal made the cloud business case for you, here is how to turn a vSphere estate into a cloud target — starting from an export you can generate this afternoon.
Start with what you already have: an RVTools export
You don’t need a discovery project to begin. RVTools (free) exports your entire vCenter inventory to a spreadsheet in minutes: every VM with its vCPUs, memory, provisioned and used disk, OS, power state, and network. The vInfo, vDisk, and vNetwork tabs are the raw material for the whole migration. Export it, and you have a factual inventory instead of tribal knowledge.
Right-size on the way out — don’t pave the cow paths
The number one mistake in VMware-to-cloud moves is mapping a 16 vCPU / 64 GB VM that averages 8% utilization to an equivalent cloud instance and then being shocked at the bill. On-prem, over-provisioning was free-ish; in the cloud it is a monthly line item. Use the used-vs-provisioned columns in your RVTools export to size for reality, not for what someone requested in 2019.
Decide the strategy per VM (the 6 R’s)
Not every VM should become a cloud VM. Walk each one through the 6 R’s: the file server might replatform to managed storage, the SQL box should almost certainly replatform to a managed database, the unused dev VMs retire, and the vendor appliance you can’t touch rehosts as-is. A pure lift-and-shift of every VM is the fastest path off VMware and the slowest path to cloud value — aim for a blend.
Design the target, don’t just list it
A spreadsheet of "VM → instance type" is not a migration plan; it ignores networking, identity, security groups, and data services. Turn the inventory into an architecture. In CloudForge you can build the target-state design on a visual canvas — VNet/VPC, subnets, the rehosted VMs, the replatformed databases, load balancers, storage — or describe a cluster of VMs to Vani and let it propose the cloud-native target. Because it’s a real design and not a drawing, it carries the resource types that generate working IaC.
Generate the landing zone and workload IaC
From the target design, CloudForge generates Terraform (or Pulumi, ARM, Bicep, or CloudFormation) with a plan diff, security scan, and approval gate. Deploy the landing zone first — networking, identity, guardrails — then the workloads in waves. Because the infrastructure is defined as code, standing up an identical DR region or a second environment later is a copy, not a project.
Migrate, validate, decommission
Use the cloud-native migration service (Azure Migrate, AWS MGN, GCP Migrate to Virtual Machines) for the actual VM replication and cutover. After each wave, validate the running estate against your CloudForge design with drift detection — anything that doesn’t match is either a migration miss or an undocumented change worth knowing about. Only when a wave is confirmed healthy do you power down the vSphere originals and stop paying for them.
The point of leaving VMware
The goal isn’t just a cheaper hypervisor bill — it’s infrastructure you can reason about, version, and rebuild. A vSphere estate that lived in vCenter and a few people’s heads becomes a versioned design plus generated IaC. That is the real dividend, and it compounds long after the migration is done.