The VMware renewal quote arrived. Here's how to actually leave.

You know the meeting. Someone forwards the renewal quote, the room goes quiet, and then finance asks the question you don't have a good answer to: why is this three times last year? Since the Broadcom acquisition, that's been the story on repeat — perpetual licenses gone, everything rebundled, priced per core with a minimum that assumes you're bigger than you are. For a lot of shops the number stopped being a line item and became a strategy meeting.

So you're leaving. Fine. But the worst version of this is the panic exit — someone spins up Proxmox on a spare box over a weekend, moves a few VMs by hand, declares victory, and then spends the next quarter finding out what didn't come across. Let's not do that. The quote is a deadline, not a fire.

Where the VMs actually go

Your realistic destinations, and what each one actually costs you in the parts nobody puts on the slide:

• KVM / libvirt — the boring, correct answer for a lot of people. It's in the kernel, it's free, and every cloud you'll ever touch runs on it underneath. The tradeoff is you're assembling the management layer yourself, or paying someone (Red Hat, SUSE) for one.
• Proxmox VE — genuinely good, and the darling of the exodus for a reason: it gives you the cluster-and-console experience without the per-core bill. Just go in knowing it's a smaller company and it's ecosystem is younger than what you're leaving.
• OpenShift Virtualization (KubeVirt) — the right call if you're already heading toward Kubernetes and want your VMs and containers under one control plane. Heavier to stand up; pays off if that's where the org is going anyway.
• Nutanix, or a public cloud — both real options. Both also trade one vendor relationship for another, so price the second lock-in before you sign, not after.

There's no wrong answer on this list, only wrong reasons. "It was on a spare server" is a wrong reason.

The migration you didn't budget for

Here's the part that blows up timelines. Moving off VMware looks like one project — get the VMs onto the new hypervisor — but it's usually two migrations wearing one trench coat.

The first is the obvious one: the virtual machine itself. Disk format (vmdk to qcow2 or raw), the boot path, ripping out VMware Tools and making sure virtio drivers are actually present so the thing boots on KVM instead of hanging on a black screen. Tedious, well-trodden, fine.

The second one is hiding inside your guests, and it's the one that had a real effect on every timeline I've watched: a huge share of those VMs are running CentOS 7, which went end-of-life in June 2024. So the moment you open them up to move them, you're staring at an OS migration too. Do both at once, blind, and you'll never know whether the thing that broke was the hypervisor move or the distro jump. (We wrote a whole piece on the CentOS 7 half of this, because it deserves its own headache.)

Decide deliberately: rehost the VM as-is first and modernize the OS as a separate, provable step, or do the OS rebuild and land it fresh on the new platform. Both are defensible. Doing them accidentally, at the same time, is not.

“It booted” is not “it's the same”

The failure mode on a VMware exit isn't the VM that won't start. Those you notice immediately. It's the one that starts fine and is subtly not the machine it was — a mount that didn't come across, a kernel parameter that got dropped, a service that's masked on the new box for reasons nobody wrote down. Everything's green until the one night it isn't.

If you're moving anything an auditor, a regulator, or a very angry customer will ask about later, "it booted and looks fine" is not an artifact you can hand anyone. You want a record: here's what the source had, here's what the target has, here's where they differ and why that's okay.

Where a tool helps, and where it's just honest

This is roughly why vrtmv exists. It reads a VMware disk image cold — you point it at the vmdk, it never boots the thing or needs vCenter creds — works out what the guest actually runs, and emits an Ansible role or Terraform to rebuild it on the target you picked. Then, after the rebuild, it diffs the new machine against what it promised and signs the result. Equivalent, partial, or failed.

I'll be square about the boundary, because a tool that oversells this is worse then useless: it plans and proves the migration, it does not magically teleport your data. Bulk data moves through a runbook you run, with checksums, and it will flat-out refuse to dump a clustered database rather than pretend that's safe. If a vendor's deck says "lift-and-shift everything automatically, zero downtime, no risk," go and count your backups.

A plan that survives the renewal date

• Inventory before you move. Read every VM cold and write down what's actually on it. The CMDB is lying to you; it always is.
• Pick the hypervisor on merits, not on what was already racked.
• Separate the two migrations. Hypervisor move and OS modernization are different risks; don't blur them.
• Rebuild and verify before you decommission anything on the VMware side. The old cluster is your rollback until you can prove you don't need it.
• Keep the evidence. A signed parity record per machine is what turns "trust me" into "here."

The renewal quote is annoying, but it's also the cleanest forcing function this industry has handed anyone in years. Estates that quietly rotted on an old hypervisor for a decade are finally getting looked at. Use the deadline. Just don't let it make the decisions for you.