VMware to Kubernetes in the GCC: OpenShift Virtualization vs KubeVirt vs Harvester Exit Cost Model

If you are leaving VMware for Kubernetes, the three serious options are Red Hat OpenShift Virtualization, upstream KubeVirt and SUSE Harvester, and all three run your VMs on KVM through KubeVirt. The real difference is cost structure: OpenShift trades higher subscriptions for less in-house effort, KubeVirt is free to license but expensive in skills, and Harvester sits in between.

That framing matters because most VMware exit conversations in the GCC start with a renewal quote that shocked someone in finance, then jump straight to “which product is cheapest”. The licence line is the easy part to compare. Migration effort, skills and day 2 operations are where budgets actually go, so that is what this cost model focuses on.

Why are GCC organisations leaving VMware?

Since Broadcom completed its VMware acquisition, the licensing model has changed in ways that hit most customers:

• Perpetual licences are no longer sold. Everything is a subscription.
• Per-core pricing in large bundles: VMware Cloud Foundation (VCF) and vSphere Foundation (VVF) replaced most of the old a la carte SKUs.
• A 16-core minimum per CPU applies. A reported jump to a 72-core minimum in April 2025 was walked back within days after customer pushback, according to heise and other trade press.

What does that cost you? Honestly, nobody outside your Broadcom account team can say. Broadcom does not publish list prices, and Broadcom told heise it “has never announced a price change”. Third-party advisors fill the gap with estimates: ThinkOn, a VMware-based service provider, reports renewals running 2x to 5x prior perpetual-plus-support costs in the Australian market, with small estates hit hardest, and licensing advisors such as Redress Compliance publish per-core benchmarks. Treat all of these as directional. The only number that belongs in your business case is your own quote.

The GCC proof point most people cite is Emirates NBD. The bank presented its move from VMware to OpenShift Virtualization at Red Hat Summit 2025, naming rising virtualization costs as a main driver, and TechTarget later reported it had moved more than 9,000 VMs. That is a vendor-backed story, but it is public and it is local.

What is actually different between OpenShift Virtualization, KubeVirt and Harvester?

KubeVirt is the open source project that adds a VirtualMachine resource to Kubernetes and runs each VM inside a pod using KVM and QEMU. It joined the CNCF in 2019 and has been an incubating project since April 2022. There has been public talk of graduation around the v1.8 release in 2026, but the CNCF project page still lists it as incubating, so that is what we report.

OpenShift Virtualization is Red Hat’s supported KubeVirt, included with every OpenShift edition. Red Hat also sells OpenShift Virtualization Engine, a VM-only edition aimed squarely at VMware exits. Reseller listings show it sold per bare-metal node, but check the exact metric with Red Hat before you model it. VM migration uses the Migration Toolkit for Virtualization (MTV), which Red Hat includes with OpenShift and which supports cold and warm migration from vSphere.

Harvester is SUSE’s open source hyperconverged platform: KubeVirt for compute, Longhorn for replicated storage, and Rancher integration for management. The software is free on GitHub, and SUSE sells support for it under the SUSE Virtualization name. VMware imports go through the vm-import-controller add-on, which connects to vCenter and converts disks.

Upstream KubeVirt on your own Kubernetes distribution is the do-it-yourself path. For migration, Forklift is the upstream open source project behind Red Hat’s MTV and targets KubeVirt directly.

How do the three options compare on exit cost?

This is a directional model, not a quote. “Low” and “High” are relative to the other two options for a typical mid-size GCC estate of a few hundred VMs.

Two things fall out of the table. First, the subscription gap is real but often smaller than the skills gap. A team of experienced vSphere admins does not become a Kubernetes platform team in a quarter. Second, because all three share KubeVirt, a move from one to another later is far easier than leaving vSphere was.

Which option fits which GCC organisation?

• Banks, insurers and government entities with strict support requirements: OpenShift Virtualization. Risk committees want a vendor on the hook, and there is a public bank-scale reference in Dubai. Budget for the subscription and save on in-house build.
• Mid-size enterprises and SaaS companies with a small platform team: Harvester. A free core with optional SUSE support, an appliance-like install and built-in storage suit teams that want to stop paying VMware without building a platform from scratch.
• Telcos, cloud providers and teams that already run Kubernetes at scale: upstream KubeVirt on your existing distribution. You already pay for the skills, so the licence saving is real.
• Edge and branch sites with a handful of hosts: compare carefully. Small VMware estates often see the largest percentage increases, but a three-node Harvester or KubeVirt cluster still needs someone who can operate it remotely.
• Organisations under data residency rules (UAE, KSA, Qatar): all three run on-premises or in local data centres, so residency rarely decides it. Your support and audit requirements will.

What does a VMware to Kubernetes migration look like?

1. Inventory and classify (weeks 1-2). Export every VM with CPU, memory, disk, OS, network and owner. Tag each as migrate, rebuild as containers, retire or keep on VMware for now. Expect a meaningful share to fall into retire or containerise.
2. Model cost and pick a platform (weeks 2-3). Put your actual Broadcom quote next to subscription, hardware and people costs for each option. Run a small proof of concept with your hardest workload, usually a Windows VM with a licensing dongle or a database.
3. Build the landing zone (weeks 3-8). Bare-metal nodes, storage, VLAN or overlay networking that matches your current segments, backup, monitoring and RBAC. Keep VM networking boring at first: bridge to existing VLANs and change one thing at a time.
4. Migrate in waves. Start with stateless, low-risk VMs, then move up. Use warm migration where the tooling supports it to shrink downtime, and swap VMware Tools for VirtIO drivers on Windows guests.
5. Decommission and renegotiate. Every wave you finish shrinks the core count you need at renewal. Time your waves against the renewal date so the next VMware quote covers only what is left.

The bottom line

The cheapest VMware alternative on paper is not always the cheapest one to run. OpenShift Virtualization buys you support and a known path, Harvester gives you a lower-cost supported platform for smaller teams, and upstream KubeVirt pays off only if you already have the platform engineers. Start from your own Broadcom quote, cost the skills honestly, and plan in waves timed to your renewal.

Our VMware Exit Assessment is a fixed-scope, three to four week engagement: VM inventory and classification, a cost model built on your real quote, a platform recommendation across OpenShift Virtualization, Harvester and KubeVirt, and a wave plan your team can execute or hand to us. See our Kubernetes migration service for how we run the migration itself, or book a VMware exit scoping call.