The VMware renewal shock calculator

Why renewals jumped

What changed when Broadcom took over VMware, the reasons behind the bill on this page.

• Perpetual licenses were retired, it's subscription-only now, billed annually.
• 160+ products were collapsed into a handful of bundles (VVF and VCF), so you buy more than you used.
• Pricing moved to per physical core, with a 16-core minimum billed per CPU.
• Widely-reported renewal increases of 3–10×, the reason this calculator exists.

Counting your cores correctly

Almost every wrong estimate on this page comes from the same place: counting the wrong thing. Per-core licensing counts physical cores in the hosts, which is usually a very different number from the one your team quotes from memory.

• Physical cores, not vCPUs. The total vCPU count allocated to your VMs is irrelevant to licensing, and it is normally much larger than the physical core count because of overcommitment. Licensing does not care how many VMs you run.
• Cores, not threads. Hyper-threading makes a 32-core host present 64 logical processors. Licensing counts the 32. If your number came from a tool showing logical processors, it is roughly double what it should be.
• The per-CPU minimum applies to every socket separately. This is the detail that surprises people with older or smaller hardware. A dual-socket host with 8-core CPUs does not bill 16 cores, it bills the minimum twice. Hosts with fewer cores per socket than the minimum are the worst value in the estate under this model, and they are worth identifying specifically.
• Count every host, including the ones nobody thinks about. The DR site, the management or edge cluster, dev and test, and hosts that are racked and licensed but idle all count. Estates routinely find ten to twenty per cent more hosts than the original list when someone actually checks.
• Mixed hardware means counting per host. If your hosts are not identical, an average multiplied by the host count will be wrong. Sum each host individually.

The reliable source for these figures is your own inventory rather than an estimate. In vCenter the per-host CPU and core count is on each host's summary tab; if you would rather not walk them one by one, an RVTools export has it on the vHost tab, and our estate analyzer will total the physical cores across the whole estate in the browser and flag the hosts that sit below the per-socket minimum.

What this estimate deliberately leaves out

This calculator is built to answer one question quickly: is the increase in the tens of per cent, or is it a multiple? It is not built to reproduce your quote, and several things that materially change the final figure are not modelled here.

• Which bundle you land on. The editions differ substantially in per-core price and in what they include. Two estates with identical core counts can receive very different quotes because they were steered to different bundles, so the bundle named on your quote is the first thing to check.
• Capabilities that used to be separate purchases. Software-defined storage, networking, and management tooling may be included in a bundle, priced as add-ons, or licensed on their own metric such as capacity. If you previously bought these individually, comparing licence to licence without accounting for them will mislead you in either direction.
• Support tier and term. Support level, contract length, and whether you prepay all move the number, and they are among the easier things to negotiate.
• Minimum commitments. Quotes can carry minimum quantities that apply per order rather than per host, which can matter a great deal to a small estate. Read the minimum stated on your own quote rather than assuming the one in this model applies to you.
• Discounting. List price is a starting position, not an outcome. Partner and reseller pricing, existing relationships, and the credibility of your alternative all move the final figure.

Treat the output as an order-of-magnitude gauge that tells you how seriously to take the renewal, then model your specific case in the 3-year TCO calculator, where support tiers and migration cost are editable.

What to do once you have the number

A large number is not automatically a decision to migrate. There are three real responses, and the strongest position is one where all three are genuinely available to you.

Reduce what you are licensing. Because the bill is driven by physical cores, consolidating onto fewer, denser hosts is a lever that does not require leaving. So is decommissioning: powered-off VMs, abandoned dev environments, and hosts kept for a project that ended are all licensed capacity delivering nothing. This is often the fastest saving available and it is worth doing regardless of what you decide next. The limits are real though, since consolidation changes your failure domains and can affect guest operating system licensing, so it is a design exercise rather than a spreadsheet one.

Negotiate. Renewal pricing is not fixed, and the single thing that most improves your position is a credible, dated alternative. A team that can show a costed migration plan with a start date is having a different conversation from one that cannot. This is worth doing even if you fully intend to stay.

Migrate. If the economics hold after an honest accounting of the work, the destinations are mature and well documented. The thing to check first is not the hypervisor comparison but the runway: our renewal planner back-schedules the phases from your renewal date and tells you whether it fits, and it is worth reading the contract's notice period before trusting any date, since that deadline usually falls months earlier than the renewal itself.

If you have not settled on a destination, the Alternative Finder ranks the options against your constraints rather than in the abstract, and the switching cost calculator puts a one-time figure on the move for the business case. For the full picture of what leaving involves, start at the VMware alternatives guide.