Hello and welcome back to Architecting Zero Downtime Infrastructure.
Today we’re tackling one of the most anxiety-producing shifts happening in data centers right now: the great VMware exodus. Between the licensing changes, the per-core pricing shock, and the strategic uncertainty, what used to be a comfortable “we’ll just renew” conversation has become a genuine board-level strategic imperative.
I recently sat down with someone who didn’t just talk about leaving VMware — he actually did it. David led his team through a full production migration to Proxmox VE. No smoke, no mirrors, and (most impressively) no meaningful downtime.
What follows isn’t theory. It’s the real story — the good, the painful, the “we definitely didn’t see that coming” moments — straight from the trenches.
The Catalyst: When Cost Meets Control
Every big IT project needs a spark. For many organizations, Broadcom’s VMware licensing changes provided a five-alarm fire.
I asked David the question I ask every leader in this situation: Was this really about money, or was something deeper going on?
His answer didn’t surprise me, but it was refreshing to hear it said out loud.
Yes, the financial pressure was real. The new subscription model and core-based licensing delivered a budget forecast that made leadership’s eyes water. But beneath the numbers was a strategic realization: they were tired of being locked into a vendor’s roadmap. They wanted to own their architecture again.
The move wasn’t just about escaping rising costs. It was about reclaiming control.
That’s a distinction that matters. Organizations that only focus on the sticker price often make reactive choices. The ones that treat it as a strategic repositioning tend to build much stronger foundations.
The Bake-Off: Finding the Right Successor
Once the decision was made, David’s team ran a proper evaluation. They looked at XCP-ng, Hyper-V, oVirt, and Proxmox.
I love a good scorecard, so I asked him about his.
Their non-negotiables were:
– Strong live migration capabilities
– Integrated, enterprise-grade backup
– Solid storage options (they wanted to use Ceph)
– An active community and commercial support availability
– Reasonable learning curve for the team
Proxmox won for three reasons that continue to resonate with me.
First, it offered an open-source core with optional commercial support — the best of both worlds. Second, its integrated storage and backup features dramatically reduced complexity compared to bolting separate solutions together. And third, the philosophy just felt right. It respected engineers instead of trying to hide the Linux underneath.
As David put it, “We wanted to understand our infrastructure again instead of just clicking through wizards.”
I felt that in my soul.
The Proof of Concept: Try to Break It
Here’s my unbreakable rule: Never trust a datasheet. Make it cry in a lab first.
David’s team built a small three-node cluster and went to war with it. They tested live migration under load, validated the backup system with real data, and deliberately tried to break storage failover.
The learning curve was real. After years in the polished vCenter interface, Proxmox’s web UI felt… different. But once they pushed past the initial “where’s the button?” frustration, they discovered something surprising: the UI was actually more transparent about what was happening under the hood.
Pleasant surprise: Hardware passthrough (especially for GPUs) was dramatically easier than they expected.
Early gotcha: Their monitoring tools didn’t always interpret Proxmox’s metrics the same way, forcing them to rethink some of their alerting logic.
The PoC wasn’t just technical validation — it was confidence building. By the end, the team wasn’t just convinced. They were excited.
The Migration: Phased, Planned, and (Mostly) Boring
This is where migrations die or succeed.
David’s approach was textbook perfect: start boring. They began with development and non-critical systems. Each successful wave increased both skill and organizational comfort.
For VM conversions, they landed on a combination of qm importdisk and virt-v2v depending on the workload. The networking translation was, as expected, where the most brain cycles were spent. Mapping vSphere port groups and vSwitches to Linux bridges and bonds required careful documentation, but once the patterns were established, it became surprisingly routine.
The entire migration was completed in carefully orchestrated phases over several months. The business never felt it.
That’s the dream.
The Moment Everything Got Weird
Of course, no migration this size gets through unscathed.
I asked David for the war story — that one moment where the documentation failed and engineering skill had to take over.
His answer involved Ceph, a particularly noisy Microsoft SQL Server, and some very confused OSDs.
The database was generating I/O patterns that caused Ceph to constantly rebalance. Performance tanked. The team found themselves deep in the weeds of CRUSH maps, PG tuning, and network latency between nodes.
The solution wasn’t in any official guide. It came from a late-night forum thread, a very patient community member, and some creative adjustments to both the Ceph configuration and the SQL Server’s storage layout.
This is my favorite part of these stories. The technical solution was interesting, but the real lesson was that they had built enough institutional knowledge by that point to even know where to look for help.
The Human Side: Moving People, Not Just VMs
Here’s what many technical leaders get wrong: they treat the migration as purely technical.
David’s team invested heavily in the human transition. They created hands-on labs, ran “Proxmox Fridays,” and deliberately paired their strongest VMware engineers with the new platform. Instead of telling people their skills were obsolete, they positioned the change as leveling up their infrastructure skills.
The shift from point-and-click vCenter to Proxmox’s combination of GUI and CLI was a feature, not a bug. Once the team saw how much faster they could work at the command line, resistance melted away.
Life After VMware: The Report Card
Six months later, what actually changed?
The numbers are impressive:
– 62% reduction in virtualization costs
– Noticeable performance improvement on storage-intensive workloads
– Dramatically faster provisioning (LXC containers are now used heavily alongside traditional VMs)
– Much greater visibility into what’s actually happening on the hosts
Most importantly, David’s team feels in control of their infrastructure again. They can implement new capabilities without waiting for a vendor’s roadmap or paying for new licensing tiers.
They’re not just running VMs differently. They’re thinking differently about their entire stack.
My Three Biggest Takeaways for You
After listening to David’s experience, three truths stand out:
- The financial pressure is real, but the strategic opportunity is bigger. Don’t just optimize for cost — optimize for control and flexibility.
- Planning beats heroics every single time. The teams that succeed are the ones that build small labs, document dependencies, and move methodically.
- The community is your hidden accelerator. David’s team repeatedly found answers in the Proxmox forums that saved them days of troubleshooting.
Final Advice from the Trenches
If you’re standing at the beginning of this journey, here’s the distilled wisdom:
Start tiny. Build a three-node lab. Break things. Rebuild them. Get comfortable before anything production touches the new platform.
Audit everything. Map every dependency, every network flow, every backup job. This work feels slow until it saves you from a catastrophic surprise.
Bring your people with you. This isn’t just a technology change — it’s a capability upgrade. Treat it that way.
David, thank you for sharing your journey with such honesty and clarity. Your story is going to save a lot of teams from learning these lessons the hard way.
And that, my friends, brings us to the perfect setup for our next episode.
We’re getting tactical.
Next time: “Proxmox 101: Moving Your VMs Without Losing Your Mind” — a practical, step-by-step guide for engineers ready to roll up their sleeves.
You won’t want to miss it.
In the meantime, I’d love to hear from you. Are you currently wrestling with a VMware migration decision? What’s your biggest concern? Drop your thoughts in the comments or reach out on LinkedIn.
Until next time, keep building infrastructure that doesn’t break when the world changes.
— Your infrastructure mentor