Leaving VMware: 300 VMs to OpenStack in six waves
How we would approach a VMware exit for a manufacturing company facing a sharp renewal increase, with a plant ERP that cannot afford a bad weekend.
This is a composite example built from requirements that are common in mid-sized enterprises. It is not a specific client engagement, and the figures are design targets for the scenario, not measured results.
A renewal quote and a fixed date
The company ran about 300 VMs on a six-host vSphere cluster: plant ERP, MES on the shop floor, email, file servers, HR and a long tail of small applications. The VMware renewal quote under the new subscription model was several times the previous support cost, and the renewal date was seven months away.
The IT head had two constraints: the ERP could only be touched on a planned weekend, and the infrastructure team of four could not double in size to run a new platform.
Most VMs were easy. A few were not.
- About 85 percent of VMs were standard Linux and Windows servers with no special dependencies.
- Two vendor appliances were supported only on VMware.
- The MES system licensed itself against a MAC address.
- Several Windows VMs ran old versions that needed virtio drivers added before conversion.
- Dependency mapping showed the ERP talked to eleven other systems, four of which nobody had listed.
That last point alone justified two weeks of discovery before any conversion.
Target platform and waves
| Component | Design |
|---|---|
| Control plane | 3 nodes, also running network gateways |
| Compute | 7 KVM hosts, sized for current load plus one spare and growth |
| Storage | 5-node Ceph cluster, NVMe for databases, three copies of all data |
| Deployment | Kolla-Ansible, so the in-house team can run upgrades |
| Backup | New backup for KVM, tested before the pilot wave |
| Kept on VMware | The two vendor appliances, on a small licensed host, until the vendor certifies KVM |
| Wave | What moves | Why in this order |
|---|---|---|
| 1 (pilot) | 15 test and tool VMs | Prove the tooling, drivers and runbook |
| 2 | 40 file, print and intranet VMs | Simple workloads, quick wins |
| 3 | 50 small business apps | Builds speed with low risk |
| 4 | HR, email and collaboration | Business-visible, but well understood |
| 5 | MES, after fixing the MAC licence binding | Plant-facing, so tested with shop-floor users |
| 6 | ERP and the systems it depends on | Most critical last, on a planned weekend |
The safety net
Every wave was converted and tested on KVM while the VMware VMs stayed live. Only after the application owner signed off were users moved. The VMware copies stayed intact, powered off, for two weeks after each wave. The vSphere licence was kept for one extra month after the final wave, so a rollback remained possible right up to the end.
Before and after (design targets)
| Before | After (target) | |
|---|---|---|
| Hypervisor licence cost | Large renewal increase | Platform subscriptions and support only |
| VMs on VMware | 300 | 2 vendor appliances |
| Upgrades | Done by the vendor partner | Run by the in-house team with runbooks |
| New VM for a project | Ticket to IT, days | Self-service portal, minutes |
| Rollback during migration | Not applicable | Available for every wave |
What we would flag
- No automatic load balancing like DRS. Capacity is planned with more headroom and reviewed monthly.
- New skills for the team. Two engineers need OpenStack and Ceph training, and the first upgrade should be done together with us.
- Two platforms for a while. Until the appliances are certified for KVM, a small VMware footprint remains.
- Testing time is the real bottleneck. Application owners must make time to test each wave, or the plan slips.
See the method in detail on VMware to KVM migration, including an animated wave simulation.
Planning a cloud move or a VMware exit?
Send us a VM inventory export (RVTools is fine) and a line on what is driving the change. We will come back with a plain first view: what could move where, in what order, and roughly what it would cost to run.