Leaving VMware: Should You Lift Your VMs into Kubernetes, or Modernise into Containers?

Most teams leaving VMware do not arrive with a clean architectural question, they arrive with a renewal quote. Broadcom’s retirement of perpetual licensing has turned that quote from a line item into a board-level concern, with Forrester citing anecdotal increases of 400% to 700% and smaller compute providers facing figures higher still.

That pressure is already turning into movement. A January 2026 CloudBolt survey of North American enterprises found that 86% were actively reducing their VMware footprint, and that 44% had already moved at least a quarter of their estate off it. Forrester puts around a fifth of the world’s largest enterprises on a path off VMware entirely.

That urgency tends to compress two very different decisions into one.

The first decision is whether to leave VMware, and for many organisations the renewal quote has already answered that.

The second decision is the one that determines whether the migration will succeed: once they leave, where will the workloads land?

The reflex answer is to swap one hypervisor for another. Proxmox, Nutanix and OpenStack each offer a broadly like-for-like replacement for vSphere, and for a team that wants to change as little as possible, moving the estate across is the path of least resistance. It gets the organisation off the licence with the operational model mostly intact, and for some estates that is a reasonable place to stop.

What a hypervisor swap does not do is change what the estate can become. A pure hypervisor hosts virtual machines and little else, so the day a workload is ready to become containers, that modernisation happens on a different platform, after a second migration. The licensing problem is solved and the modernisation problem is left exactly where it was.

Landing on Kubernetes keeps both futures on one platform, and it is the path we assess, so it is the one this post is about. Choosing it still leaves a decision to make on each workload: carry it across unchanged, or reshape it. The two destinations look alike while behaving very differently in practice:

• They can lift the virtual machines more or less as they are into Kubernetes using KubeVirt, keeping the VM as the unit of deployment.
• Or they can modernise the workloads into containers, and change the unit of deployment entirely.

Both run on Kubernetes, both leave VMware behind, and both are defensible. The right choice ends up being not a preference, but a function of what each specific workload is and what the organisation needs from it over the next few years.

Both destinations also keep the workloads on infrastructure the organisation controls. Leaving VMware this way need not relocate anything to public cloud; both paths can run on the same on-premises hardware, avoiding the egress costs and latency that send teams back from the cloud in the first place.

We run KubeVirt feasibility assessments against actual customer estates as a three-week VMware Kubernetes Migration pilot, and the guidance below is drawn from that hands-on work rather than from the documentation. The gotchas we flag are ones we have hit in practice.

In short, for the reader who needs the decision and not the detail:

• Lift the bulk of the estate into Kubernetes with KubeVirt to escape the licensing pressure quickly, and modernise into containers selectively where a workload is actively developed or needs to scale.
• The choice is per workload, not per estate. Most organisations end up with a deliberate mix, plus a tail of decommission candidates the exercise surfaces.
• The framework further down is a short checklist a team can run against its own workloads to sort them.

The fork once Kubernetes is the destination

Let us say we have an estate of a few hundred virtual machines. Some are commercial off-the-shelf appliances delivered as a VM image, some are stateful databases that have run untouched for years, some are internally built services that a development team still ships to weekly. And a long tail are machines that nobody is entirely sure are still needed.

The instinct under time pressure is to treat this estate as a single entity and pick one answer for all of it. That instinct is understandable, but it rarely survives contact with the estate.

A commercially available off-the-shelf (COTS) appliance and an actively developed internal service have almost nothing in common from a migration perspective. Forcing both down the same path either over-invests effort on workloads that will never benefit, or under-invests on the ones where the benefit is the entire point of leaving.

Before choosing a tool, it helps to be precise about what the two tools do.

Option A: Lift the VMs with KubeVirt

KubeVirt is a CNCF project that runs virtual machines as first-class workloads inside Kubernetes. The VM becomes a VirtualMachine custom resource, scheduled onto nodes alongside Pods, using the same cluster, the same networking, and the same storage primitives. Red Hat’s OpenShift Virtualization is the most widely deployed productised form of this approach, but the underlying engine is KubeVirt and KVM, the same Linux virtualisation technology that has run production workloads for well over a decade.

The appeal it has is directness. The guest operating system does not change, the application inside it does not change, and in most cases the operational shape the application teams understand does not change either. What instead changes is the platform underneath, which moves from a VMware licence to a Kubernetes cluster the organisation controls. For a workload that cannot be containerised, or simply should not be touched, this is the pragmatic answer.

“Lift and shift” can imply less work than it actually involves. In practice:

• The migration itself is a disk conversion and a re-platforming exercise. Tooling exists to import VMDK disks and to automate much of the conversion, but performance characteristics, especially storage I/O and network throughput, need validating against representative workloads, and not just assuming parity.
• The VM is still a VM. Patching the guest, managing its lifecycle, and carrying its full operating system footprint all remain the team’s responsibility. KubeVirt changes where the VM runs; it does not change the fact that it is a VM with everything that entails.
• The operational model is new, even if the workload is not. The team now reasons about virtual machines in terms of Pods, storage classes, and other first-class citizens in Kubernetes. This is a proper skills shift. The workload looking familiar just disguises how different the platform beneath it has become.

And there are also a few specifics which tend to surface late:

• Live migration depends on shared storage. Live migration is the thing most teams assume they are getting for free because they had it on vSphere, yet it depends on ReadWriteMany shared storage. An estate whose storage only offers ReadWriteOnce will install KubeVirt cleanly, and then quietly lack the capability the team was counting on.
• The guest agent is the piece most often missing. The qemu-guest-agent is the component most commonly absent from imported guests. Without it, the cluster cannot coordinate graceful shutdown or report the guest’s true state.
• Imported guests need their drivers added. Disk import runs through the Containerized Data Importer, converting VMDK images into DataVolume resources. Guests that were never given virtio drivers will need them before they can perform sensibly.

None of these are a blocker on its own. Collectively they will decide whether a team meets these constraints during planning (or in the middle of the migration itself).

KubeVirt is not meant to modernise anything. It gives an organisation a credible exit from VMware without enforcing a rewrite, and it buys time to modernise later on the team’s own schedule, as opposed to under renewal pressure.

In our technical demo on migrating from VMware to Kubernetes, we walk the lift through from end to end, including the disk data migration and the cutover.

Option B: Modernise into containers

The other path changes the unit of deployment. Instead of carrying the virtual machine across, the workload is repackaged to run as a container, removing much of the operating system layer, and deploy the application as a Kubernetes first-class citizen rather than bundled in a VirtualMachine.

This is more work up front, but it is the path where the full benefits of Kubernetes live.

A containerised workload can be scaled horizontally, scheduled densely, rolled out and rolled back declaratively, and integrated into the same autoscaling and observability patterns as the rest of a cloud-native platform. Where KubeVirt preserves the workload, containerisation re-shapes it into something the platform can do more with.

In our technical demo on going cloud-native after VMware, we have shown what that re-shaping looks like for a working service, including the production hardening and a zero-downtime switchover.

The qualifications matter here too:

• Not every workload will be a candidate. A COTS appliance delivered as a sealed VM image generally cannot be containerised by the customer at all, and a workload with deep host-level dependencies may resist it strongly enough that the effort will outweigh the return.
• The effort is proper engineering effort. Containerising a stateful application means understanding its state, its configuration, its startup behaviour, and its failure modes well enough to express them as Kubernetes resources. For an application nobody has rebuilt in years, that understanding sometimes has to be reconstructed before any modernisation can begin.
• The payoff is a day-2 platform, not a finished migration. The value of containerisation accrues over the months and years after the move, in faster deployment cycles, denser resource usage, and lower operational toil. If a workload will see no further development and rarely scales, much of that payoff will never arrive, and the up-front effort will be harder to justify.

If we were to characterise the distinction simply: KubeVirt is the right tool when the goal is to leave VMware safely. Containerisation is the right tool when the goal is to leave VMware and get materially more from the workload afterwards.

Option C: The hybrid path most enterprises take

Presented as a binary, this looks like a single high-stakes choice. In practice, the estate makes the decision for the organisation, because it contains workloads that point in both directions at once.

Run the estate against a short checklist and most of it sorts quickly. The archetypes from the start of this piece tend to fall out like this:

The phased pattern we see hold up well is to lead with KubeVirt for the bulk of the estate, escaping the licensing pressure quickly, and then to modernise selectively where the return is clear. That defuses the second decision: an organisation does not have to settle the final destination of every workload before it can leave VMware. It decides what moves first, lifts that onto a platform it controls, and then makes each modernisation call one workload at a time, funded by the savings from the lift.

The substance of our Workload Modernisation pilot is picking the destination workload by workload, and it is a far calmer exercise once the licensing clock has stopped.

The costs that do not appear on the licence

Both paths reduce or remove the VMware licence, and neither is free. The costs that never reach an invoice are the ones that decide whether a migration is judged a success a year later.

With KubeVirt, the cost is ongoing and operational. The organisation still runs full virtual machines, still patches guests, and still carries the footprint, now on a platform its team is learning. The learning curve bites hardest during an incident, when a team is slower to diagnose and recover on a system it does not yet know by reflex and the vSphere muscle memory of years no longer applies. That is itself an argument for leading with the lift: it keeps each workload’s shape familiar while the team builds fluency, instead of changing the workload and its foundations at once.

With containerisation, the cost is the up-front engineering, set against a day-2 platform that lowers operational cost over the months that follow.

Where to start

The most valuable thing a team leaving VMware can do is resist answering the second decision for the whole estate at once. The estate is not uniform, the right answer differs by workload. Getting it wrong means either wasted modernisation effort, or a lift that locks in operational toil that never needed to exist.

That sorting is the work we do, and we do it independently. We do not sell a hypervisor, so our recommendation on any given workload is the one supported by evidence, including “leave this one alone” or “this one is not worth modernising”.

We run it as a three-week, time-boxed pilot, working alongside the organisation’s own VMware specialists against live workloads. We document every constraint and operational requirement we hit, so the output is a per-workload decision the team can act on, rather than a slide deck.

If a renewal is approaching and the destination question is still open, that is the moment to assess it. Our VMware Kubernetes Migration page covers how the lift pilot runs, while our Workload Modernisation pilot covers what to containerise once the licensing clock has stopped. If it is easier to talk it through first, our Technical Review is where that process starts.