VMware to KVM: The Complete Migration Guide

KVM — the Linux kernel-based hypervisor — has become the default Plan B for organisations exiting VMware. It is mature, performant, free at the hypervisor layer, and supported commercially through multiple vendors (Red Hat OpenShift Virtualization, Oracle Linux Virtualization Manager, SUSE Harvester, Proxmox VE, and stacks built directly on libvirt). For workloads where VMware's premium features are not justified by Broadcom's new pricing, KVM is the technically credible exit path.

This guide walks through the complete migration framework — strategy selection, tooling, workload assessment, cutover patterns, and the operational changes that come with the new platform. It assumes you are evaluating KVM seriously, not just speculatively, and need a working plan that can stand up to executive scrutiny.

Why KVM is the technical favourite for VMware exit

KVM sits in the Linux kernel itself. Every major Linux distribution ships with it, every major cloud provider builds on it, and the user base is in the tens of millions. The technical maturity gap that existed five years ago is largely closed: KVM supports live migration, distributed storage, software-defined networking, GPU passthrough, encrypted memory, secure boot, and virtually every enterprise feature VMware customers expect.

What KVM does not provide out of the box is the integrated management experience VMware offers through vCenter. That gap is filled by management layers — Red Hat OpenShift Virtualization, Nutanix AHV, Proxmox VE, oVirt, OpenStack, or custom libvirt-based stacks. Choosing the right management layer is the single most consequential decision in a VMware-to-KVM migration.

Step 1 — Choose the management layer

The KVM ecosystem offers five mainstream management options, each with different trade-offs.

Red Hat OpenShift Virtualization runs VMs alongside containers on the same Kubernetes platform. Best fit: organisations already on OpenShift or planning a container-first future. Commercial support and clear ecosystem direction. Higher learning curve for traditional VM admins.

Proxmox VE is open-source with a clean web UI and active community. Best fit: mid-market customers prioritising cost and operational simplicity. Excellent for lift-and-shift migrations. Limited enterprise features compared to OpenShift Virtualization or Nutanix AHV.

Nutanix AHV is technically KVM-based but delivered as an integrated HCI appliance. Best fit: organisations wanting a turnkey commercial alternative with hardware and software in one stack. Higher upfront cost than pure-software options.

oVirt is the upstream open-source project that powered the now-discontinued Red Hat Virtualization. Best fit: organisations comfortable with community-supported infrastructure and DIY operational tooling.

SUSE Harvester is a Kubernetes-native HCI platform built on KVM. Best fit: SUSE-aligned organisations or teams wanting modern HCI without the OpenShift footprint.

For most VMware customers we work with, the choice narrows to OpenShift Virtualization (for container-future organisations) or Proxmox VE (for traditional VM-first organisations). The decision should be driven by where your application portfolio is heading, not just where it is today.

Step 2 — Assess the workload portfolio

Not every VMware workload migrates cleanly to KVM. The assessment phase categorises workloads into four buckets.

Easy migration (60-75% of typical estates): Standard Linux and Windows workloads with no VMware-specific dependencies, running on supported operating systems with virtio drivers available. These move with standard migration tooling in hours per VM.

Moderate migration (15-25% of typical estates): Workloads with VMware-specific networking (distributed switches, NSX security policies), shared VMDKs, or non-standard storage configurations. These require explicit re-architecture as part of the migration but are technically straightforward.

Hard migration (5-15% of typical estates): Workloads with deep VMware integration — vSphere APIs, vRealize Automation blueprints, custom storage policies, or hypervisor-specific licensing. These need re-platforming work that goes beyond migration tooling.

Block migration (1-5% of typical estates): Workloads on operating systems without virtio support, with hardware passthrough that does not translate, or with vendor support contracts that explicitly exclude KVM. These either stay on VMware or are decommissioned.

The assessment output is a workload-by-workload classification with effort and risk estimates. It becomes the basis for the migration wave plan in step 3.

Step 3 — Plan the migration waves

Almost every successful VMware-to-KVM migration runs in waves rather than as a single cutover. Typical wave structure:

Wave 1 — Pilot (4-6 weeks): 20-40 workloads from the easy category, ideally non-production. Validates tooling, processes, and operational runbooks. Discovers issues that the documentation did not predict.

Wave 2 — Production easy workloads (8-16 weeks): The bulk of the easy migration category. Runs in parallel with continued operations on VMware. Produces the most cost savings per unit of effort.

Wave 3 — Moderate workloads (8-12 weeks): Workloads requiring re-architecture. Slower per-workload but unlocks the higher-value applications.

Wave 4 — Hard workloads (12-24 weeks): Re-platforming work for the deepest VMware integrations. May overlap with vendor disengagement and Broadcom renewal timing.

Wave 5 — Block decisions: The remaining 1-5% of workloads. Each one decided individually — stay, decommission, or replace.

Step 4 — Select the migration tooling

The tooling landscape has matured significantly. The leading options:

Migration Toolkit for Virtualization (MTV): Red Hat's tool, built into OpenShift Virtualization. Handles VMware to KVM cold and warm migration via vSphere API integration. Best fit for OpenShift-target migrations.

virt-v2v: The classic open-source VM converter. Mature, well-documented, works for any KVM target. Requires more manual steps than MTV.

Proxmox VMware Import: Proxmox VE 8 ships with VMware import tooling that handles direct ESXi-to-Proxmox conversion. Excellent for Proxmox-target migrations.

Veeam: Backup vendor with cross-platform restore that supports VMware-to-KVM as a restore operation. Slower than purpose-built migration tooling but works when other tools fail.

Carbonite (OpenText) Migrate: Commercial migration tool with continuous replication for near-zero-downtime cutovers. Best for workloads where extended downtime is unacceptable.

For most engagements, the tooling decision follows the management-layer decision: OpenShift target → MTV; Proxmox target → Proxmox VMware Import; other targets → virt-v2v with workflow automation layered on top.

Step 5 — Re-architect networking and storage

The most under-estimated part of VMware-to-KVM migration is the networking and storage re-architecture. NSX-T does not exist on KVM; vSAN does not exist on KVM; vCenter folder structures and tags do not exist on KVM.

For networking, the typical replacements are Open vSwitch (for L2 and basic L3), OVN (for software-defined networking), and Cilium or Calico (for container-aware networking on OpenShift Virtualization). Security policies that were implemented in NSX need to be re-expressed as Kubernetes NetworkPolicies, OVN ACLs, or firewall rules — depending on the target platform.

For storage, the replacements are Ceph (the dominant choice for OpenShift and oVirt), ZFS (Proxmox's default), or vendor storage arrays via standard protocols. vSAN's tight integration between hypervisor and storage does not translate; you either move to Ceph for similar integration on KVM, or accept a more traditional shared-storage model.

Step 6 — Operational readiness

The day-to-day operational experience on KVM is different from VMware, and the difference is mostly about tooling unfamiliarity rather than capability gaps. Your VM admins need training on the chosen management layer, your backup admins need to validate that their tools support the target platform, your monitoring tools need to be re-pointed, and your runbooks need to be rewritten.

Plan 4-8 weeks of operational ramp-up for each major operational team (infrastructure, security, backup, monitoring) before they take on production support. The investment in training is small compared to the cost of operational incidents in the first six months post-cutover.

Step 7 — Don't burn the bridge with Broadcom too early

This is the strategic point that most migration guides miss. Even if KVM is your destination, do not signal an aggressive exit to Broadcom in the months before your renewal. Broadcom's pricing leverage is largely informational — the less they know about your alternatives plan, the more flexibility you have at the negotiation table.

, the firm we recommend most often for Broadcom audit defence and renewal negotiation, builds the migration narrative into renewal conversations strategically. The goal is to extract maximum value from the final VMware contract — typically a bridge contract covering the migration window — while preserving the optionality to walk away if Broadcom does not move on price.

TCO benchmarks: VMware vs KVM

For a typical 500-host VMware estate, the three-year TCO comparison looks roughly as follows. VMware (post-Broadcom subscription, VCF Standard): $9-15M depending on negotiated price per core. KVM on Proxmox VE: $2-4M (mostly hardware refresh and Proxmox enterprise support). KVM on OpenShift Virtualization: $4-7M including OpenShift subscription. KVM on Nutanix AHV: $6-9M depending on hardware refresh timing.

The savings are real but not free. Add migration project cost ($1-3M for a 500-host environment), operational training, and short-term productivity drag, and the breakeven typically lands at 14-20 months. Beyond breakeven, the savings compound annually because KVM does not have an equivalent of Broadcom's price-increase trajectory.

The risks worth taking seriously

VMware-to-KVM migration is not free of risk. The three failure modes worth planning for explicitly are: vendor support gaps for applications that explicitly require VMware (some ISVs still ship support matrices that exclude KVM, though this is shrinking); operational capability gaps if the team has only ever run VMware (mitigated by training and phased waves); and management-layer immaturity for niche features like specific GPU configurations or licensing dongles (mitigated by pilot testing those workloads first).

None of these risks are deal-breakers, but they need to be surfaced in the business case rather than discovered halfway through the migration.

Final thought

KVM is the most technically mature exit path from VMware, and the cost savings are real enough to justify the project work for most enterprise VMware customers. The keys to success are choosing the right management layer for your future architecture, planning waves carefully, and not signalling the exit to Broadcom until you have extracted the final round of renewal value. Done well, a VMware-to-KVM migration is a 12-24 month project that resets infrastructure economics for the next decade.

Frequently asked questions

How long does a typical VMware-to-KVM migration take?

For a mid-size enterprise (200-500 hosts), end-to-end migration typically takes 9-15 months from kickoff to cutover. Pilot waves complete in 4-6 weeks; the bulk of production migration takes 6-9 months running in parallel with VMware operations; final cleanup and decommissioning runs another 2-3 months. Larger enterprises can stretch to 18-30 months if there are significant re-architecture requirements.

What is the realistic cost saving compared to staying on VMware?

Steady-state savings of 60-80% on the licensing line are typical for KVM-on-Proxmox migrations. OpenShift Virtualization migrations capture 50-65% savings because the OpenShift subscription offsets some of the gain. The full three-year TCO including migration project cost typically lands at 35-55% net savings versus a continued VMware path.

Will our existing backup, monitoring, and security tools work on KVM?

Most enterprise backup tools (Veeam, Commvault, Rubrik, Cohesity) support KVM. Most monitoring tools (Datadog, Dynatrace, New Relic) work via OS agents and are platform-agnostic. Security tools are more variable — endpoint detection works fine, but VMware NSX-specific security policies need to be re-implemented natively on the target platform.

Can we run VMware and KVM in parallel during migration?

Yes, and this is the recommended approach. Parallel operation is the only way to migrate in waves rather than as a high-risk single cutover. The cost during the overlap period is the sum of both platforms, but the overlap window is bounded (typically 6-12 months) and the avoided risk is worth the temporary cost duplication.

What happens to our VMware certifications and skills investment?

Most VMware admin skills translate to KVM management with 4-6 weeks of focused training. Networking and storage skills carry over almost entirely. The most VMware-specific skills (vSphere automation, vRealize, NSX-T) require more re-investment, but most teams find KVM operations no harder than VMware once they are over the initial unfamiliarity curve.

Is there a hybrid option — keep some workloads on VMware and migrate the rest to KVM?

Yes, and this is a common outcome rather than a compromise. Many enterprises end up with 70-90% of workloads on KVM and the remaining 10-30% (deep VMware integration, vendor support constraints, specific feature dependencies) staying on VMware at a much smaller licensing footprint. The hybrid model captures most of the savings while preserving optionality for workloads that genuinely need VMware.