Most VMware advice published in the last two years has a conclusion built into the headline. Either the licensing is now indefensible and you must leave, or migration is a trap and you should sign. Both positions are being argued by people selling the destination.
The useful frame is narrower and less satisfying: your renewal quote is a number, an exit is a different number, and the second one is mostly staff time that nobody puts on a slide. This post is about getting both numbers honest.
What changed, and what it costs you
We’re gmware, a software development firm headquartered in Austin, TX with engineering centers in Bangalore and Mohali, India. Infrastructure modernization and cloud migration are things we sell, so weigh what follows accordingly. It is also why we would rather tell you the exit is expensive now than discover it with you in month four.
What actually changed
Broadcom completed its acquisition of VMware in November 2023. Weeks later, on December 11, 2023, it announced the end of sale for VMware perpetual licenses in a newsroom post titled “VMware by Broadcom Dramatically Simplifies Offer Lineup and Licensing Model,” bylined by Krish Prasad, SVP and GM of the VMware Cloud Foundation Division. The plan was to complete the transition of VMware solutions to subscription licensing, retiring perpetual licenses and Support and Subscription renewals on those licenses. Broadcom’s knowledge base points to the detail in KB 309138, “VMware End Of Availability of Perpetual Licensing and SaaS Services.”
Two consequences matter for a budget:
Subscription replaced a sunk cost. A perpetual license with support renewals is an expense you had already partly absorbed. A subscription is a recurring line that appears in full every term. Even at identical annual spend, this changes how the number reads to a CFO, and it removes the option of running unsupported-but-owned software as a stalling tactic.
Bundling replaced à la carte. A long catalog collapsed into a small number of bundles. If you ran a modest vSphere deployment and used a fraction of what a bundle contains, you are now paying for the bundle. Packaging, rather than the per-core rate alone, is a large part of why renewal quotes rose sharply for estates that had not grown.
Per-core pricing carries a 16-core-per-CPU minimum, which Broadcom’s own product documentation states as the minimum license capacity you can purchase. A lightly populated socket still bills at 16 cores. That penalizes exactly the estates least able to absorb it: small clusters, edge sites, branch hosts.
About the 72-core number
You will see it everywhere, and it deserves a caution rather than a citation.
In April 2025, CRN reported, citing a distributor memo, that the minimum number of cores required for VMware licenses would increase from 16 to 72 effective April 10, 2025. The reporting did not agree on the unit. CRN’s quoted memo wording was 72 cores “per command line.” Licenseware published a correction describing a minimum purchase of 72 cores per product, not the per-CPU requirement initially reported. Other accounts described both thresholds applying at once, with the customer owing whichever figure came out higher. Several outlets subsequently reported that Broadcom walked the change back, leaving 16 cores per CPU as the stable rule. And yet material published well after that reversal still describes a 72-core minimum per license instance as live.
We are not going to resolve that here, and neither should your budget. Note also that the reversal reports trace to distributor and reseller accounts rather than a named Broadcom statement, which is exactly why the record stayed muddy. The practical instruction is: get the applicable minimum in writing from your reseller, for your quote, for your term.
This is also a decent test of an advisor. Anyone quoting the 72-core figure to you flatly, without the disagreement over units or the reported reversal attached, is reading headlines rather than contracts.
Costing the exit properly
The mistake in most migration business cases is that the license saving is precise and the project cost is a placeholder. Reverse that. Licenses are the easy number. Here is what actually consumes the budget:
Discovery comes first, because you cannot migrate an estate you have not inventoried. Hosts, sockets, cores per socket, VM counts, which vSphere features are genuinely load-bearing versus habitual, and which workloads have compliance constraints on where they run. On an estate that has grown for a decade, expect to find machines nobody owns. Budget for the archaeology, because the alternative is finding a dependency during cutover.
Rebuilding the surroundings is the line that gets missed. vSphere is rarely alone. Backup and disaster recovery integrations, monitoring agents, network and storage configuration, and years of accumulated automation all assume the platform underneath. Those do not migrate. They get rewritten and retested against the new platform. If your team invested heavily in vSphere-specific automation, that investment is the thing you are writing off, not the licenses. It is also the line with the widest spread between estates, which is why a vendor quoting a per-VM migration price without asking what your automation looks like is quoting the wrong unit.
Parallel running is unavoidable: you will operate both platforms during cutover. As a planning heuristic, assume you pay for both for a period measured in months for anything non-trivial, and confirm it against your own cutover plan rather than a vendor’s. Business cases that model an instant switch understate cost and overstate the first-year saving.
People are the quiet cost. Operators who are expert in one hypervisor are competent-at-best in another for a while. That gap shows up as slower incident response and more change failures during exactly the window when you can least afford them. Budget training time and expect a temporary productivity dip rather than pretending it away. Retention matters here too: plan for the possibility that a migration is when a specialist tests the market, because losing your most vSphere-fluent engineer mid-cutover is a schedule risk, not just a staffing one.
Refactoring catches the stragglers. Some workloads will not move cleanly. Anything pinned to specific hardware passthrough, licensing tied to host identity, or an appliance the vendor only supports on vSphere. These become their own small projects, and they are usually found late. Flush them out during discovery by asking every application owner one question: what breaks if this VM gets a new virtual hardware identity?
The four destinations, honestly
Hyper-V is the strongest fit if you already carry Microsoft licensing and management tooling, because some of the cost is already sunk and the operator skills are adjacent. Weakest if your team is Linux-first.
Proxmox VE is attractive where you have genuinely Linux-competent operators and want out of per-core pricing, since Proxmox subscriptions are priced per CPU socket rather than per core. The trade is that you are taking on more of the operational burden yourself, and commercial support looks different from what an enterprise procurement team expects.
Nutanix and comparable hyperconverged platforms let you keep a commercial support relationship and a vendor to escalate to, and you pay for it. The right question is whether the new pricing model is structurally better for your estate shape or merely different, which is a contract question, not a technology one.
Public cloud is the option chosen most often for the wrong reason, which is that a licensing dispute feels like a good moment to modernize. Sometimes it is. But treat “cloud will be cheaper per unit of compute” as a condition to test in your own model rather than an assumption, because lifting a virtualized estate into someone else’s virtualized estate does not automatically reduce unit cost unless the workloads are genuinely elastic or you are prepared to re-architect them. Our notes on cloud migration cost for small business and Azure versus AWS for cloud migration cover that ground in more detail.
None of these is a drop-in replacement for a mature vSphere estate. Any vendor implying otherwise is quoting the VM moves and omitting the surroundings.
Do this before the renewal meeting
The single highest-return move is building your own inventory first, because it serves both paths. Host and socket counts, cores per socket, which bundle components you actually deploy, and which workloads are genuinely tied to platform features. With that in hand, three things become possible: you can challenge a quote on specifics, you can price an alternative against a real baseline, and you can tell the difference between a renewal that is expensive and one that is mispriced for your estate.
Then run both numbers to the same standard. Renewal over three years, fully loaded. Migration over the same three years, including parallel running, retraining, rewritten automation, and the workloads that need refactoring. If migration still wins, you have a real business case rather than a reaction. If it does not, you have the data to negotiate, which was worth building anyway.
The worst outcome is neither staying nor moving, but discovering the renewal number six weeks before the term ends with no inventory and no alternative priced. That is the position a late renewal leaves you in, and it is largely avoidable if you start a quarter out.
How gmware runs a VMware exit assessment
We start with the inventory, because every path needs it, and it has to be current to be useful. Hosts, sockets, cores per socket, bundle components actually in use, and a dependency map for the automation and backup integrations that surround vSphere. That artifact is yours regardless of what you decide, and it is the thing that turns a renewal conversation from a vendor’s framing into yours.
From there we cost two scenarios to the same standard, renew and exit to a named destination, with the labor lines filled in rather than estimated as a placeholder. Where the exit wins, the same cloud consulting and DevOps and IT infrastructure teams do the rebuild work: automation, monitoring, backup integration, and the operator enablement that decides whether the new platform is actually operable on day one. Reach out with your renewal date and your host count, and we will tell you which of the two numbers you are missing.
Related reading if the estate also carries end-of-support operating systems: Windows Server 2016 end of support and legacy application modernization cost.