We've had four separate conversations this quarter with teams mid-evaluation on leaving VMware. Different industries, different scale, same underlying question once you get past the pricing complaint: not "should we leave," but "in what order, and what does each step actually cost us."
That's the gap I want to close here: three posts already covered the case for leaving, the licensing math, and the bare metal option. None of them get into sequencing, so that's what this one covers.
What's actually changed since we wrote the pricing math?
I'm not going to re-litigate the pricing argument in detail (we covered the licensing math already), but the short version: if your workloads are containerized and your platform team manages clusters rather than VMs, you're paying six or seven figures a year for a virtualization layer that isn't doing much for you anymore. Since Broadcom, that number has moved in one direction, and it isn't down.
What's changed since we wrote that post is how much of this is now active, not hypothetical. Across the accounts we're talking to right now, we've got teams testing Proxmox performance against their existing VMware setup on their own workloads, teams mid-PoC on Azure and AWS ahead of a full migration, and teams still working out whether their container infrastructure decision even has a clear direction yet. This isn't a wave that's coming. It's the wave we're in the middle of.
Which of the three options actually fits your workload?
We've already made the case for each of these individually. Side by side, the trade-off gets easier to see:
| Nutanix | Proxmox | Bare metal Kubernetes |
|---|
| Licensing | Proprietary, still paid, but cheaper than post-Broadcom VMware | Open source, optional paid support tier | No hypervisor license at all |
| Vendor lock-in | Yes: different vendor, same shape of problem | No | No |
| Operational shape | Closest to what you're already running | Same VM-carving model as VMware, different vendor | No VMs, containers run directly on hardware |
| Flexibility | High: can still run non-containerized workloads | High, same reason | Lower: everything must be containerized |
| Best fit | Pick this if procurement won't budge on "we need a vendor to call." Fair enough, but you're still buying lock-in, just from someone new. | The one we see teams pick most often: same operational muscle memory as VMware, without paying for it. | The cleanest cut, if your workloads are actually ready for it. Most aren't yet. That's a "when," not a "no." |
None of these is "the answer." Which one fits depends on your workload mix, and I'd rather you make that call with the trade-offs laid out than with a vendor's framing of the decision.
So what do you actually move first?
Order matters more than most teams assume going in.
| Stage | What it covers | Risk level | Why here |
|---|
| Lock this first | The container-infrastructure decision itself: K3s vs. full Kubernetes vs. something else | Not a migration risk, a sequencing risk | Everything below assumes this is already decided. Change it mid-migration and the plan built on it unravels. |
| Move first | Fully containerized, stateless workloads | Low: mostly organizational, not technical | Builds momentum and surfaces process problems before you hit anything that matters if it breaks |
| Move second | External state, no exotic storage requirements | Moderate: cutover timing needs care | Infrastructure decision is usually straightforward; the risk is in the handoff, not the tech |
| Move last, or not yet | Anything with an untested storage-performance dependency | High until you've tested it yourself | One manufacturing customer's own benchmarks showed their existing setup 2–4x faster than Proxmox on their storage backend, because it used a different storage driver. Don't assume newer means faster. Test first. |
The one row worth re-reading: lock the infrastructure decision before anything else on this table. We've seen migrations stall because teams started moving workloads before that call was actually made.
Why does this always take longer than planned?
I'd rather tell you this now than have you find out mid-migration. Timelines slip. One customer of ours told us a Proxmox migration for their factory environment "might come next year, unsure," which is a perfectly reasonable place to be, and a more honest one than most vendor timelines admit to. Migrations get reprioritized against other work. Teams get partway through an evaluation and hit a security or compliance question that adds months, not because anyone did anything wrong, but because that's how enterprise infrastructure decisions actually go.
Build the slippage into your plan from the start. Assuming you'll be the exception is the actual risk here, not the migration itself.
Why can one platform carry all three paths?
The reason Giant Swarm can support Nutanix, Proxmox, and bare metal through a single platform is Cluster API (CAPI), a Kubernetes sub-project that provides a declarative, infrastructure-agnostic way to provision and manage clusters. Each infrastructure target has its own CAPI provider implementation, but the operational model on top (GitOps, upgrades, observability) stays the same regardless of which hypervisor decision you land on.
That matters for sequencing specifically: it means the choice of Nutanix vs. Proxmox vs. bare metal doesn't have to be a single irreversible bet made on day one. Teams can (and do) run mixed environments during a transition, sequencing workload migration without forcing a company-wide infrastructure decision to happen all at once.
Where do you actually start?
If you're evaluating a post-VMware path, the sequencing above is the order I'd actually follow. Those four conversations we had this quarter didn't end with four different plans. They ended with roughly this one, adjusted for whatever each team's storage layer turned out to actually do under load. If yours would be conversation five, you know where to find us.
