Dora NodaA UK university's annual VMware bill went from £40,000 to nearly £500,000. Not over five years — the next renewal. The university didn't add capacity, didn't sign up for new features, and didn't ask for the change. Broadcom mandated the full VMware Cloud Foundation bundle, and the invoice followed the licensing math, not the workload.
That's a 1,150% increase on one campus's IT budget line, and it isn't the outlier the number makes it sound like. It's the predictable output of a formula every VMware customer is now subject to, and the size of the hit depends almost entirely on one variable: how many CPU cores sit in each of your physical hosts. Below, the actual math for four fleet sizes — from a small edge deployment through a 1,500-core enterprise estate — plus what "just move to Kubernetes" really requires once you decide the number is the last straw.
The Three Changes That Turned a Renewal Into a Reset
Broadcom's VMware repricing isn't one price hike — it's three structural changes stacked on top of each other, and each one removes an option a customer used to have.
Perpetual licenses ended in February 2024. Every VMware customer, no exceptions, now buys a subscription. There's no more "pay once, patch forever" option to fall back on — the recurring bill is now permanent by design, not a choice you opted into.
Broadcom collapsed more than 8,000 SKUs into four bundles. The old catalog let a customer buy exactly what they used — vSphere alone, or vSphere plus vSAN, without NSX networking they didn't need. That catalog is gone. Today there are four options: VMware Cloud Foundation (VCF), VMware vSphere Foundation (VVF), vSphere Standard, and vSphere Enterprise Plus. A customer who only ever wanted standalone vSphere Essentials Plus — since discontinued — now buys into a bundle carrying NSX and vSAN whether or not either gets used.
The per-CPU core minimum quadrupled. Effective April 10, 2025, the licensing floor rose from 16 cores per CPU to 72. A single 8-core processor — common in edge nodes, retail point-of-sale boxes, and older rack servers — now licenses as if it had 72 cores. That's not a rounding adjustment; it's paying for 64 cores that don't exist and never will.
Any one of these changes would be a real cost increase. Stacked together — subscription-only pricing, forced bundle upsell, and a core-count floor that ignores your actual hardware — they produce a multiplier that behaves completely differently depending on what your server room looked like before Broadcom's acquisition closed.
What Four Different Fleets Actually Pay
The "800–1,500%" headline number isn't an average — it's the top of a range that's driven almost entirely by how many cores sit in each of your physical hosts. The fewer cores per host you were running before, the harder the 72-core floor hits, because you're licensing the same fixed minimum against a much smaller base. Here's that mechanism working across four real, documented fleet profiles:
| Fleet profile | Cores per host | Before (annual) | After (VCF, annual) | Increase |
|---|---|---|---|---|
| Edge/branch/POS (Essentials Plus tier) | 8 or fewer | $10,000–$15,000 | $80,000–$200,000+ | 533%–2,000% |
| UK university (mandated full VCF) | Mixed, low-density | £40,000 | ~£500,000 | ~1,150% |
| Mid-size org, 10 servers × 2 CPUs | 16 | Baseline vSphere pricing | Licensed for 1,440 cores (10 × 2 × 72) | 500%–600% |
| Large enterprise estate | High-density, ~1,500 total cores | $400,000 | $525,000 | 31% |
Read left to right and the pattern is exactly the licensing mechanism, not luck: an edge server with 8 physical cores gets billed for 72 anyway, a ninefold markup on capacity that was never provisioned. A mid-size shop running 16-core CPUs still gets rounded up to 72 per socket, landing in the 500–600% band. A large estate that was already running dense, high-core-count hardware barely notices the floor — its per-host core counts were already close to or above the new minimum, so the 31% increase is closer to a normal subscription-versus-perpetual-plus-support delta than a shock.
The honest takeaway isn't "everyone gets hit 1,000%." It's that the exact people least likely to have budgeted for a repricing event — universities, retail chains, branch offices running lean edge hardware — are structurally the ones the 72-core floor punishes hardest. A team running dense compute already priced closer to what Broadcom now charges regardless of the change.
The Industry Hasn't Actually Left Yet — the Numbers Say So
The sentiment shift is real and it's already showing up in survey data. Gartner's January 2026 poll of 182 IT leaders found 76% hold negative sentiment toward Broadcom's VMware ownership, 67% are actively evaluating alternatives, and 35% have committed to a full migration plan.
But intent and completion are two different numbers, and the completion number is much smaller. In the same dataset, 86% of organizations report actively reducing their VMware footprint in some way — yet only 4% have finished a full replacement. 44% have migrated a quarter or more of their workloads off VMware; just 2% have crossed 75%. Gartner's own projection puts the halfway mark — half of enterprise VMware workloads migrated — at 2028, not this year or next.
That gap between "actively looking" and "actually done" is the tell. It's not that alternatives don't exist — public cloud IaaS already leads adoption at 72% among migrating workloads, followed by Microsoft's virtualization stack at 43%, with Proxmox and Nutanix AHV picking up open-source and commercial share respectively. It's that migrating a production virtualization layer is genuinely slow, even when the financial case for leaving is this stark. Which is exactly why the next section matters more than the pricing table.
The Honest Scope: Bare-Metal Kubernetes Doesn't Make VMs Disappear
Here's where a lot of "just move to Kubernetes" advice quietly oversells the swap. A Cluster-API-managed bare-metal Kubernetes fleet — using KubeVirt to keep running existing VMs alongside containers — replaces the virtualization layer. It does not replace the application-modernization work still sitting on top of that layer, and pretending otherwise is how a migration project blows its timeline.
The parts that genuinely are straightforward: compute and storage. A lift-and-shift rehost moves a VM into a KubeVirt-managed pod on a Kubernetes node with the OS, applications, and configuration left unchanged. That part of the pitch — "your existing VM just runs somewhere else now" — is accurate.
Networking is where the honesty has to kick in, because it's where real migrations actually stall:
- Live migration breaks with bridge networking. KubeVirt's live migration handles memory and disk state well, but it doesn't cleanly support VMs using a bridge network interface — a very common VMware setup — so a migration that was supposed to be transparent to the running workload isn't, in practice, for a meaningful share of existing VMs.
- IP addresses don't survive the move. When a VM lands in the new environment, it gets a fresh IP from the Kubernetes pod CIDR — not the address it had on the old VMware network segment. Every firewall rule, DNS record, and load-balancer config that referenced the old IP is now silently wrong until someone finds and fixes each one.
- The team, not just the tooling, resists. In field reports on VMware-to-KubeVirt migrations, 38% of organizations cite internal cultural pushback from staff with deep VMware expertise as a real blocker — and a comparable share separately flag limited enterprise-grade support and difficulty standing up KubeVirt itself as a distinct, additional obstacle.
None of that is a reason to stay on VMware at 1,000% pricing. It's a reason to budget the migration as what it actually is: a networking and operations project with a virtualization-layer swap inside it, not a virtualization-layer swap that happens to also touch networking. A team that scopes only the easy 80% — compute and storage rehost — and treats the IP/firewall/DNS cleanup and the live-migration edge cases as an afterthought is the team that ends up mid-migration for eighteen months instead of six.
What Actually Disappears Once You Own the Hardware
The reason this repricing event is pushing enterprises toward bare-metal Kubernetes instead of just another hosted hypervisor is specific, not generic anti-Broadcom sentiment: a Cluster-API-managed fleet has no per-core license meter to hit a floor on in the first place. There's no vendor SKU catalog that can collapse from 8,000 options to four bundles, because there's no bundle — you're running the Kubernetes control plane and scheduling primitives directly against machines you own, with no licensing agent counting cores against a minimum you didn't ask for.
That's also the precise scope of what changes and what doesn't. Cluster API and its Hetzner provider (CAPH) solve node lifecycle — declarative provisioning, scaling, and replacement of the physical or virtual machines underneath a cluster. They don't solve the application layer sitting on top, and they don't turn a stateful legacy VM into a twelve-factor container by themselves. That's the same honest boundary bex operates inside: a git-push deploy onto Cluster-API-managed machines you own removes the control-plane rent and the licensing-floor risk, but it doesn't pretend the workload doesn't need to actually run well on the new substrate.
For a team that's already decided the VMware math doesn't work anymore, that's the right order of operations — pick infrastructure with no core-count floor to get hit by next time, and then do the modernization work deliberately, instead of discovering the IP-address problem in production during a forced migration.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on Cluster API-managed machines you own, with no per-core meter and no vendor bundle to be re-priced into. Star the repo on GitHub or deploy your first app today.
