The bill arrived, and you were not ready for it.
That is not a criticism, because nobody was. When Broadcom bought VMware in November 2023 for $61 billion and immediately ended perpetual licensing, the industry watched and waited. Then the renewal quotes came in, and the waiting stopped. Customers reported increases of 200% to 500% as the baseline, and some saw 800% or more.
A Rimini Street survey of 111 VMware customers in late 2024 found 98% are using, planning to use, or considering VMware alternatives. Gartner predicts VMware’s market share falls from 70% in 2024 to 40% by 2029. The migration wave is already moving. Organizations that started evaluating alternatives in 2024 finished their migrations in 2025 on their own terms. The ones waiting until renewal pressure forces their hand are making rushed decisions on a deadline.
We built Orion to run VMs and containers on the same Kubernetes cluster, so we have been deep in this conversation for two years. Here is what we have actually seen, and where the standard migration advice falls short.
What Broadcom actually changed
The specifics matter here, because “they raised prices” undersells how much the structure changed.
Broadcom eliminated perpetual licensing entirely. Every VMware customer now pays an annual subscription whether they want one or not. They introduced a 72-core minimum per order, effective April 2025, so small and mid-size deployments pay for capacity they do not need. They added a 20% penalty for missing renewal anniversary dates, applied retroactively. And they bundled products customers used to license separately into VMware Cloud Foundation, forcing adoption of components many customers have no use for.
The price shock is real, and so is the structural problem behind it. You are now renting what you used to own, on a schedule you did not pick, at a price that compounds every renewal.
Why most migration guides miss the point
The standard advice goes like this. Evaluate KubeVirt, evaluate OpenShift Virtualization, evaluate Proxmox, pick one, and migrate your VMs.
That is technically correct and practically incomplete. The harder problem is the operating model your team built around VMware over the last decade.
VMware shops usually have a dedicated “on-prem” team and a separate “cloud” team, with more teams walled off for each additional environment. Each team built expertise in its own tooling, and each environment has its own provisioning process, networking model, and storage setup. Migrating off VMware means more than swapping a hypervisor. You are asking teams to rebuild habits they spent years building, on a compressed timeline, while production keeps running.
This is what bites organizations mid-migration. They pick a technically capable replacement, underestimate the organizational lift, and end up running both in parallel at a cost higher than the original VMware bill.
KubeVirt is real now
A year ago, KubeVirt was the right technical answer with an asterisk, because production readiness was uneven and enterprise support was thin.
That asterisk is mostly gone. The 2025 State of Production Kubernetes research found 86% of Kubernetes adopters know about KubeVirt and 26% run it in production. Portworx reports 5,000+ VMs running in production deployments. KubeVirt 1.8 shipped a Hypervisor Abstraction Layer that makes it vendor-neutral in practice as well as open-source in name. Red Hat ships it as OpenShift Virtualization with enterprise support. NVIDIA GeForce NOW runs GPU workloads on it in production at scale.
In practice, KubeVirt lets you run your existing VMs on Kubernetes next to your containers, on the same cluster, with the same orchestration and the same tooling. You get one operating model without rewriting the applications.
It also does not have to be all-or-nothing. You can run VMs and containers side by side during the transition and move workloads a few at a time instead of forcing a cutover. That is really the point. This should feel like something you run next to what you have, never a rip and replace.
What the migration path actually looks like
The organizations doing this well follow three phases, and the timeline is honest about the complexity.
Phase one is a pilot, usually two to four weeks. You pick five to ten non-critical workloads that represent different application types, and at least one should be a VM so you test the lift-and-shift path. You run them in parallel with their VMware versions and write down the performance and operational differences. This is where you find the surprises, on workloads that do not matter yet.
Phase two is development and test environments. They have lower SLAs and more tolerance for disruption. Moving them off VMware frees up licenses and gives your team more hands-on time with the new operating model. New workloads start deploying to Kubernetes by default.
Phase three is production. By now you have a team with real operating experience, a written list of edge cases from the pilot, and a clear cutover process. The risk at this stage is much lower than if you had jumped straight here.
In the migrations we have worked on, the VM-to-Kubernetes move is faster than expected on the technical side and slower than expected on the people side. The code moves in days. The team habits take months. Planning for that gap is what separates a migration that goes smoothly from one that stalls.
The unified compute argument
We built Orion to handle VMs, containers, and bare metal in one orchestration layer because the migration moment is exactly when the cost of fragmentation becomes visible.
Separate teams running separate stacks with separate tools add cost at every layer. You pay for duplicated expertise, duplicated tooling, duplicated provisioning, and duplicated monitoring. And when something breaks at the boundary between two environments, nobody clearly owns it.
A unified compute plane shrinks all of that. Your VMs run on KubeVirt on the same cluster as your containers, your storage has one layout, your POSIX identity model covers everything, and your monitoring watches one environment instead of three. When you need to burst a workload to cloud, you use the same provisioning path you use on-prem.
That shared operating model is what makes the post-VMware environment cheaper to run than the VMware one was, even before you count licensing.
The honest part
Not every organization should migrate right now. If you are mid-cycle on a VMware contract and the renewal is two years out, a rushed migration to dodge a future increase can cost more than the increase. The organizations making the best calls right now treat this as a commercial problem to solve, and they are not reacting to it like a crisis.
Start with three numbers: the date of your next VMware renewal, what a 300% increase at that renewal would cost you per year, and how long a phased migration would take if the pilot started today. That math tells you whether the urgency is real or manufactured.
For most organizations running production VMs on VMware right now, the math says start the pilot. The organizations that started in 2024 finished in 2025 with better options and less pressure. Waiting makes the options worse and the pressure higher.
If you want to work through what a migration path looks like for your environment, we are happy to walk through it with you. Book a time with our team
Alex Hatfield is the CEO and co-founder of Juno Innovations. Juno builds Orion, the customer-hosted unified compute plane. Orion runs inside your own environment, air-gapped by design, and gives your people one place to use the compute you already have, from GPUs and CPUs to VMs and bare metal.
WRITTEN BY
Alex Hatfield
Alex co-founded Juno to fix how enterprise compute gets done. He leads product vision and customer strategy, and spends most of his time working directly with infrastructure and research teams pushing the limits of what their hardware can do.