You don't have to replace VMware. You have to survive the bill

The bill arrived. You were not ready for it.

That is not a criticism. Nobody was. When Broadcom acquired VMware in November 2023 for $61 billion and immediately eliminated 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. Some saw 800%. Some saw 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 not theoretical. It is happening now, and the organizations that started evaluating alternatives in 2024 are finishing migrations in 2025 on their own terms. The ones waiting until renewal pressure forces their hand are making rushed decisions under time pressure.

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

It is worth being specific, because "they raised prices" undersells the structural shift.

Broadcom eliminated perpetual licensing entirely. Every VMware customer now pays annual subscriptions, whether they want to or not. They introduced a 72-core minimum per order, effective April 2025, which means organizations running small or 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 that customers previously licensed separately into VMware Cloud Foundation, forcing adoption of components many customers have no use for.

The pricing shock is real. The structural problem underneath it is also real: you are now renting what you used to own, on a schedule you did not choose, at a price point that compounds every renewal cycle.

Why most migration guides miss the point

The standard advice is: evaluate KubeVirt, evaluate OpenShift Virtualization, evaluate Proxmox, pick one, migrate your VMs.

That is technically correct and practically incomplete. The harder problem is not the hypervisor. It is the operational model your team built around VMware over the last decade.

VMware customers typically have a dedicated "on-prem" team and a separate "cloud" team, with more teams isolated to each additional environment. Each team developed expertise in its own tooling. Each environment has its own provisioning process, its own networking model, its own storage configuration. When you migrate away from VMware, you are not just swapping a hypervisor. You are asking teams to rebuild operational habits they developed over years, on a compressed timeline, while production workloads are still running.

This is the thing that bites organizations mid-migration. They pick a technically capable replacement, underestimate the organizational lift, and end up in a parallel-run state that costs more than the original VMware bill.

KubeVirt is real now

A year ago, KubeVirt was the right technical answer with an asterisk: production readiness was uneven and enterprise support was thin.

That asterisk is largely gone. The 2025 State of Production Kubernetes research found 86% of Kubernetes adopters are aware of KubeVirt and 26% are using it in production. Portworx reports 5,000+ VMs running in production deployments. KubeVirt 1.8 shipped a Hypervisor Abstraction Layer that makes it genuinely vendor-neutral, not just 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.

The practical implication: KubeVirt lets you run your existing VMs on Kubernetes alongside your containers. Same cluster, same orchestration layer, same tooling. You get the operational unification without rewriting the applications.

The cool thing about that is the migration does not have to be all-or-nothing. You can run VMs and containers side by side during the transition, moving workloads incrementally rather than forcing a cutover.

What the migration path actually looks like

The organizations doing this well are following a three-phase approach, and the timeline is honest about complexity.

Phase one is a pilot, typically two to four weeks. You select five to ten non-critical workloads that represent different application types. At least one should be a VM workload to validate the lift-and-shift path. You run them in parallel with their VMware counterparts and document 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. These have lower SLA requirements and higher tolerance for disruption. Moving them off VMware frees up licenses and gives your team more hands-on experience with the new operational model. New workloads start deploying to Kubernetes by default.

Phase three is production. You now have a team with real operational experience, a documented set of edge cases from the pilot, and a clear process for cutover. The risk at this stage is much lower than if you had jumped straight here.

What we have seen from customers going through this with Orion: the VM-to-Kubernetes transition is faster than expected on the technical side and slower than expected on the operational side. The code moves in days. The team habits take months. Planning for that gap is the difference between a migration that goes smoothly and one that stalls.

The unified compute argument

The reason we built Orion to handle VMs, containers, and bare metal in a single orchestration layer is not because we wanted to check boxes. It is because the migration moment is exactly when the fragmentation tax becomes visible.

Separate teams managing separate stacks with separate tools adds cost at every layer: duplicated expertise, duplicated tooling, duplicated provisioning processes, duplicated monitoring. When something breaks at the boundary between environments, nobody owns the problem cleanly.

A unified compute plane collapses that surface area. Your VMs run on KubeVirt on the same cluster as your containers. Your storage has one topology. Your POSIX identity model covers everything. Your monitoring covers one environment instead of three. When you need to scale a workload to cloud during a burst, you use the same provisioning path you use on-prem.

This is not just a migration convenience. It is the operational model that makes the post-VMware environment cheaper to run than the VMware environment was, even before you factor in licensing.

The honest part

Not every organization should migrate immediately. If you are mid-cycle on a VMware contract and the renewal is two years out, a rushed migration to avoid a future price increase can cost more than the increase itself. The organizations making the best decisions right now are the ones treating this as a commercial problem to solve, not a crisis to react to.

The questions worth asking: What is your next VMware renewal date? What would a 300% increase at that renewal cost annually? How long would it take your team to execute a phased migration if you started the pilot today? That math tells you whether 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 are finishing 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 specific environment, we are happy to walk through it. Book a time with our team

Alex Hatfield is the CEO and co-founder of Juno Innovations. Juno builds Orion, a customer-hosted unified compute plane that orchestrates Kubernetes, VMs, and bare metal across cloud, on-premises, and air-gapped environments.