Most VMware customers aren't leaving. They're staying, and paying more to do it.
In January 2026, CloudBolt surveyed 302 IT decision-makers at North American enterprises. 86% said they are actively reducing their VMware footprint. 54% said they are staying with VMware while they do it.
So for most teams, the question isn't which hypervisor to move to. It's how much of the current bill pays for nothing.
That waste hides in two places. The first is the gap between what you license and what you run. The second is the waste inside what you run. The licensing is specifically based on the physical CPU core. Per-core pricing makes the second gap more expensive, because every idle core still carries a license.
Here are five signs that one of those gaps is open in your estate.
Sign 1: You're licensing cores you don't have
If your licensed core count is higher than the physical cores you run, you're paying for capacity that doesn't exist. Small clusters, branch offices and edge sites are the most exposed. To check, compare licensed cores per product against physical cores per site.
In March 2025, The Register reported an email that distributor Arrow sent to its French partners. It said that from April 10, the minimum core count for VMware licenses would rise from 16 to 72. Arrow's own example made the effect clear. A server with a single eight-core processor would be licensed for 72 cores.
Broadcom did not issue a statement when the change was reported. Later reporting by heise described the 72 cores as a minimum per order, with the existing 16-core minimum per CPU still in place. How the rule applies to you depends on your contract. Check your terms before you renew.
This isn't only a small-business problem. Gartner research VP Julia Palmer has said VMware licenses are too expensive for remote office, branch office and edge locations. Plenty of large enterprises run exactly those sites.
How to check: List physical cores per CPU and per host. Total them by product. Then compare those totals with the licensed cores on your entitlement.
Sign 2: Utilization is low, but you keep buying hosts
If your clusters look full on allocation but run cold on actual use, your VMs are oversized. You end up buying hardware, and now licensed cores, to hold capacity no workload touches.
VMs get sized when someone requests them. Few get resized later. A template says 8 vCPUs, so the VM gets 8. It uses two.
Repeat that across hundreds of VMs and the cluster looks full on paper. It isn't. Under per-core licensing, every host you add to absorb that phantom demand adds cores to the bill.
Oversizing can hurt performance too. Large VMs are harder for the scheduler to place, so CPU ready time can climb even when overall use is low. Teams read that as a hardware shortage and buy more hosts. The real fix is smaller VMs.
Metrics to pull over 30 days:
- vCPU to physical core ratio per cluster
- Average and peak CPU use per VM against allocated vCPUs
- Active memory against allocated memory
- CPU ready time per VM and per host
Want a quick overview of how Calsoft runs this analysis? Download the hypervisor optimization one-pager.
Sign 3: Zombie and orphaned VMs still eat capacity
A zombie VM is powered on but has done no useful work for months. It still holds CPU, memory and storage. Under per-core licensing, physical host continues to carry the licensing cost for its cores, even when those resources are underutilized.
This is an old problem with a new price tag. In 2017, Jonathan Koomey and Jon Taylor of Anthesis published a study covering more than 16,000 physical servers and 32,000 virtual machines. About 30% of the virtual machines were comatose. The study defined comatose as no useful computing for six months or more.
That data comes from 2015, so treat it as a sign of scale, not a current benchmark. The more useful finding is what happened when one company acted. After seeing the evidence, it cut its comatose physical servers from 30% to 8% in a single year.
Zombies aren't the only dead weight. Look for VMs with no named owner, old snapshots, unused templates and powered-off VMs still holding storage.
A 30-day zombie VM audit:
- Pull every VM with near-zero CPU, network and disk activity over 30 days.
- Match each one to an owner and an application.
- Power off the unclaimed VMs. Set a retention window before deletion.
- Recalculate how many hosts you actually need.
Sign 4: You're paying for bundle features you don't use
Broadcom now sells VMware as subscription bundles. If your workloads don't use the storage, networking or operations components in your bundle, part of your spend is shelfware.
VMware Cloud Foundation combines vSphere, vSAN, NSX and the Aria suite in a single per-core subscription. That's good value if you run all of them. It's not if you run vSphere on external SAN storage with physical network segmentation. In that setup, the vSAN and NSX entitlements may sit idle.
How to check: Map each workload to the features it actually uses. Look at DRS, vSAN, NSX micro-segmentation and Aria operations.
Some workloads need only basic virtualization. Dev, test and edge are common examples. They may not justify the larger bundle, or VMware at all. A second hypervisor can make sense for them.
But a second platform brings its own costs: separate tooling, backup integration and skills. Run the numbers both ways before you split your estate.
Sign 5: Your renewal date drives your decisions, not your data
If renewal planning starts when the quote arrives, you negotiate with no usage data and no alternatives. That's the most expensive position to be in.
Lateness now has a direct cost. The same Arrow email said Broadcom would levy a 20% penalty on customers who renew after the deadline.
Moving away takes time too. Gartner's Palmer has said a full migration off VMware will take three or more years. One CloudBolt respondent put it this way: unwinding a decade of process dependencies is taking 18 to 24 months.
If your alternative takes years to build, it isn't leverage at renewal. It has to be underway before the quote lands.
Before your next renewal:
- Count physical cores by product and site
- Right-size VMs and clear out zombies
- Map features in use against your bundle
- Price at least one alternative for a subset of workloads
Do this, and the renewal conversation starts from a smaller, data-backed number.
Optimize first, then decide whether to migrate
Optimization and migration aren't rival choices. Optimization comes first either way.
If you stay, a right-sized estate means fewer cores to license. If you move, it means fewer VMs to migrate and a cleaner baseline for comparing platforms. Migrating a zombie VM to a new hypervisor just moves the waste.
When optimization is enough
Staying and tuning usually makes sense when your workloads depend on VMware features you'd have to rebuild elsewhere. NSX security policies and vSAN storage are the usual examples. Rebuilding them carries real cost and risk.
When the numbers point to a different hypervisor
Sometimes the gap won't close. Your licensed cores may stay far above your physical cores even after consolidation, as often happens at small edge sites. Or most of your workloads may use only basic virtualization.
The numbers can also move all at once. In 2024, Computershare's CTO said a quote for its hypervisor came back between 10 and 15 times higher after Broadcom's acquisition. The company decided to migrate 24,000 VMs to Nutanix.
If that's where your numbers point, compare your options in our guide to VMware alternatives. Or see how a phased VMware migration works in practice.
Quick self-check: how many of these signs apply to you?
- Do licensed cores exceed physical cores in any cluster or site?
- Is average CPU use per VM well below the vCPUs allocated?
- Do you have VMs with no named owner, or no activity in 30 days?
- Are you paying for bundle components no workload uses?
- Is your next renewal under six months away, with no usage report ready?
Each yes points to a specific place to look.
FAQs
What is VMware's 72-core minimum?
In March 2025, distributor Arrow told partners that from April 10, the minimum core count for VMware licenses would rise from 16 to 72. Later trade reporting described it as a minimum per order, with 16 cores per CPU still required. Small environments end up paying for cores they don't have. Check your own contract for how it applies.
How do I find zombie VMs?
Pull 30 days of CPU, network and disk activity for every VM. Flag the ones near zero. Confirm whether anyone owns them, then power off the unclaimed ones before deleting anything.
Does hypervisor optimization only apply to VMware?
No. Oversized VMs, zombie VMs and poor workload placement happen on Hyper-V, Nutanix AHV and KVM too. The licensing signs in this post are VMware-specific. The utilization signs apply to any hypervisor.
Find out what your hypervisor is really costing
Calsoft's hypervisor health check inventories your hosts, VMs, clusters and licenses. It then shows where cores and capacity are going unused, whether you run VMware, Hyper-V, Nutanix AHV or KVM.
