Skip to main content

VMware Exit: How We Saved $113K/Year for a Fortune 500 Client

· 4 min read
HyperSDK Team
HyperSDK Team
Core Team

When Broadcom completed its acquisition of VMware, our client -- a Fortune 500 financial services company -- received a renewal quote that was 4.2x their previous annual spend. What had been a manageable $29,000 per year for vSphere Enterprise Plus licensing was now $122,000, with no option to return to perpetual licensing. This is the story of how we helped them exit VMware entirely and reduce their virtualization costs by 93%.

The VMware Licensing Problem​

The client operated 200 virtual machines across 12 ESXi hosts running a mix of Windows Server 2019, RHEL 8, and Ubuntu 22.04 workloads. Their VMware stack included vSphere Enterprise Plus, vCenter Server, vSAN, and vRealize Operations -- a common enterprise configuration.

Under the new Broadcom licensing model, several changes hit simultaneously. Per-socket licensing was replaced with per-core subscriptions, dramatically increasing costs for their dual-socket servers. Perpetual licenses were eliminated entirely, forcing a move to annual subscriptions. Products were bundled into suites, requiring purchase of components they did not use. Support tiers were consolidated, removing the option for lower-cost support plans.

The combined effect was a renewal quote of $122,000 per year -- a 320% increase that the IT budget simply could not absorb.

The Migration Approach​

We designed a 10-week migration plan using three tools in sequence: HyperSDK for VM export from vSphere, hyper2kvm for disk conversion and guest OS preparation, and libvirt for deployment on KVM hosts.

Week 1-2: Assessment. HyperSDK connected to the client's vCenter Server and cataloged all 200 VMs, mapping CPU, memory, disk, and network configurations. We identified 15 VMs with VMware-specific dependencies (VMware Tools custom scripts, vSphere API integrations) that required additional preparation. Dependency mapping revealed that 80% of VMs could be migrated independently.

Week 3-4: Pilot. We selected 10 non-critical VMs spanning Windows Server, RHEL, and Ubuntu for pilot migration. Each VM was exported from vSphere using HyperSDK's manifest-tracked export, converted from VMDK to qcow2 with automatic VirtIO driver injection via hyper2kvm, and deployed on KVM hosts running libvirt. All 10 VMs booted successfully on first attempt. Application owners validated functionality within 48 hours.

Week 5-8: Production Migration. We migrated the remaining 190 VMs in four waves of approximately 50 VMs each. Changed Block Tracking (CBT) enabled incremental exports for VMs that could not tolerate extended downtime -- the final sync required transferring only the delta, reducing cutover windows to under 15 minutes per VM. Source VMs remained running on vSphere during validation.

Week 9-10: Validation and Decommission. Performance benchmarks confirmed that migrated VMs matched or exceeded their vSphere baseline. Backup and recovery procedures were tested end-to-end. After sign-off from all application owners, the vSphere infrastructure was decommissioned and licenses were not renewed.

Cost Before and After​

The annual cost comparison tells the story clearly. VMware licensing, support, and management tools totaled $122,000 per year. The equivalent KVM infrastructure -- including RHEL subscriptions for host OS, basic monitoring, and the HyperSDK migration license -- came to $8,800 per year. That is a $113,200 annual savings, or 93% reduction.

Over a three-year horizon, the savings exceed $339,000. The one-time migration cost (engineering time and HyperSDK licensing) was recovered within the first 6 weeks of operation.

Lessons Learned​

Three lessons stood out from this engagement. First, start with a thorough VM inventory -- we discovered 23 VMs that were powered off and had not been used in over a year. These were decommissioned rather than migrated, saving additional storage costs. Second, VirtIO driver injection is critical for Windows VMs. Without the correct storage and network drivers, Windows VMs will not boot on KVM. hyper2kvm handles this automatically, but it must be verified during the pilot phase. Third, keep source VMs running during validation. The ability to fall back to vSphere if any issue arose gave application owners confidence in the migration process.

The VMware exit is not just possible -- for most enterprises, it is the financially responsible decision. If your renewal quote has doubled or tripled, schedule an assessment to see what your organization could save.