VMware to OpenShift: What the Migration Actually Involves

Since Broadcom moved VMware to per core subscription and withdrew perpetual licences, a lot of organisations are looking at alternatives for the first time in a decade. Nutanix and Hyper V are the names that come up first, but OpenShift is climbing the list fast, especially in large enterprises that already run Red Hat and want a single strategic platform for the next ten years. This guide assumes you have already decided to evaluate leaving VMware. If you are still weighing that bigger question, start with should you leave VMware, and for the platform neutral mechanics of any migration read migrating off VMware alongside this. Here we focus on one destination and on the question people get wrong about it.

What you are actually moving to

OpenShift is Red Hat's enterprise Kubernetes platform. The part that matters for a VMware exit is OpenShift Virtualization, which runs full virtual machines directly on that platform, managed next to containers through the same console and the same tooling. Under the bonnet it is built on KubeVirt, a mature open source project, and in practice it runs your VMs as first class workloads on Kubernetes, usually on bare metal servers. The pieces worth understanding before you plan anything are these.

Your VMs run on Kubernetes, but you do not have to think in Kubernetes to run them. This is the point most people miss. OpenShift Virtualization gives you a familiar VM experience, create, start, snapshot, migrate a machine, through a console and an interface designed for that, while Kubernetes does the orchestration underneath. You can genuinely run a fleet of ordinary Windows and Linux VMs on it without containerising a single application.

There is now a VM only edition. Red Hat launched OpenShift Virtualization Engine specifically for organisations that want the virtualisation capability without paying for the full application platform. It entitles only the components needed to run VMs, which lowers the cost and simplifies the story for a buyer whose immediate goal is to replace VMware, not to go cloud native. This SKU exists precisely because so many large organisations want exactly that.

Licensing is a per core subscription. OpenShift is licensed per core on a subscription, where each core subscription typically covers two physical cores. So, as with every VMware alternative, you are not escaping the subscription model itself, you are changing who you pay and what the platform gives you for it. The honest comparison is total cost over the term against a right sized VMware renewal, including the migration and any new bare metal, not a headline sticker price.

The point people get wrong: you do not have to be cloud native

The lazy take is that OpenShift is only for organisations doing containers and microservices, and that using it just to run VMs is using a sledgehammer to crack a nut. In practice, a large and growing number of serious organisations are choosing OpenShift precisely to lift and shift their existing virtual machines, with no immediate intention of containerising anything, and for the right organisation that is a rational decision rather than a mistake.

The logic is strategic, not tactical. A big enterprise replacing VMware is making a platform choice it will live with for a decade. Choosing OpenShift means the platform that runs your VMs today is the same one that can run containers, AI workloads and modern applications tomorrow, on one operating model, one support relationship and one set of skills, rather than buying a pure virtualisation product now and a separate modernisation platform later. If your organisation already runs Red Hat Enterprise Linux widely, or is heading toward Kubernetes anyway, consolidating onto a single platform has real and defensible value. The VM only edition exists to make that first step affordable.

The honest pros and cons

Set against VMware and against the other alternatives, this is where OpenShift genuinely stands out and where it asks something back.

• Pro, one platform for VMs and the future. The same platform runs your virtual machines now and your containerised and AI workloads later, which is a genuine consolidation most alternatives cannot match.
• Pro, a strong migration tool and a familiar VM experience. Red Hat's tooling automates the bulk conversion, and the day to day VM operations are designed to feel familiar rather than forcing everyone to learn Kubernetes.
• Pro, open source foundations and no hypervisor lock in of the VMware kind. Built on KubeVirt and Kubernetes, it avoids a single proprietary hypervisor and fits an open, portable direction of travel.
• Pro, natural fit for a Red Hat estate. If you already run Red Hat Enterprise Linux and Ansible, OpenShift extends a support relationship and a skill set you already have.
• Con, it is a Kubernetes platform. Even in VM only form, you are adopting OpenShift, and operating it well needs platform engineering skills your VMware team may not have yet. This is the single biggest thing to plan for.
• Con, storage and networking are redesigned, not repointed. Persistent storage moves to the Kubernetes CSI model and networking to OpenShift's model, so these are rebuilds rather than a copy of your existing vSphere setup.
• Con, best on bare metal. OpenShift Virtualization is happiest running directly on physical servers, so the move often pairs with a hardware decision rather than reusing a nested setup.
• Con, the ecosystem is younger for VMs. Backup, DR and third party integrations for OpenShift Virtualization are maturing quickly and are good, but the VMware ecosystem is still deeper and longer established.

What the migration actually involves

The virtual machine cutover is the part everyone pictures, and it is rarely the hard part. The effort lives in the surrounding dependencies. Here is the honest sequence.

The tooling exists, and it is good

Red Hat provides the Migration Toolkit for Virtualization, installed from the OpenShift OperatorHub, which handles the bulk of the conversion from vSphere to OpenShift Virtualization. You connect the source and destination, map the networks and storage, and run a plan against a batch of VMs. It supports cold migration, where the VM is shut down while data copies, and warm migration, where most of the data copies while the machine keeps running and only a short cutover needs downtime. For standard server workloads this part is genuinely well trodden. The tool is not the constraint. The constraint is everything that touches those virtual machines.

What moves easily

Stateless and loosely coupled workloads move with little drama. Web tiers, application servers, test and development estates, and most general purpose Windows and Linux virtual machines convert cleanly. If your estate is mostly this, the core migration is very manageable.

What does not move easily

The hard parts are the same ones that make any hypervisor exit hard, plus a few specific to a Kubernetes platform, and they deserve naming explicitly.

• Backup and disaster recovery interlock. Your backup tooling, replication and DR runbooks are written against VMware constructs. The major backup vendors now support OpenShift Virtualization, but support is not the same as a working, tested recovery, so you are rebuilding and revalidating your recovery position, not just repointing it.
• Storage redesign. Persistent storage on OpenShift uses the Kubernetes CSI model and needs shared, live migration capable storage underneath, often OpenShift Data Foundation or a supported array. This is a design exercise, not a lift of your existing datastores.
• Networking and security dependencies. Firewall rules, microsegmentation, load balancer integrations and any third party network virtualisation need to be reproduced on OpenShift's networking model. This is a redesign in places, not a copy.
• Application support statements. Some software vendors certify their product only on named hypervisors. It usually runs fine on OpenShift Virtualization, but if you need a formal support statement for a regulated or business critical application, confirm it before you migrate that workload, not after.
• Platform skills and operating model. Your monitoring, automation and day to day runbooks assume vCenter. The OpenShift console is capable and consistent, but there is a genuine reskill onto Kubernetes concepts and a rebuild of automation to account for. This is the cost people most often underestimate.

Where OpenShift fits well, and where it does not

OpenShift is a strong platform, and it is the right answer for some estates and the wrong one for others. Being straight about both is the point.

That second column is not a dismissal. Plenty of organisations that are not cloud native today choose OpenShift on purpose, as covered above. The distinction is intent. OpenShift rewards those who mean to use the platform, and asks more than it gives back from those who only ever want a hypervisor.

The real considerations and blockers

Beyond fit, a handful of practical things decide whether a move to OpenShift goes smoothly.

• Total cost over the term. OpenShift removes the VMware subscription but adds its own, plus likely bare metal and the migration project. The VM only edition helps, and the saving is real for many estates at scale, but it is not automatic. Model the full term cost against a properly right sized VMware renewal before treating it as a saving.
• Platform skills are the critical path. The technology works. The most common cause of a hard OpenShift adoption is underinvesting in the team that runs it. Budget for training or partner support from the start, not as an afterthought.
• Bare metal and storage decisions. Because OpenShift Virtualization is best on bare metal with shared CSI storage, the move often coincides with hardware and storage choices. If a refresh is due anyway, the economics improve. If your kit is mid life, factor that in.
• The parallel run. Do not collapse the old environment until the new one has proven itself through a real recovery test and a representative workload at scale. Rushing this is where migrations go wrong.

None of this is a reason not to choose OpenShift. For a large organisation making a long term platform bet, it is a genuinely compelling destination, and the ability to run VMs today and everything else tomorrow on one platform is something the pure virtualisation alternatives cannot offer. The point is to choose it on evidence, with the skills and the blockers mapped, and with clear eyes about what you are really adopting.

Weighing OpenShift against the alternatives?

Send us your estate and your renewal position. We will give you an honest read on whether OpenShift fits, what the migration would really involve, how the total cost compares with a right sized VMware renewal, and whether a simpler alternative would serve you better. As a Red Hat and IBM partner we can also deliver it, and we will still tell you plainly when it is not the right answer. Independent advice first, delivery second.

Name *

Company *

Work email *

Phone (optional)

Details

Request a migration review

Prefer email? Reach us directly at hello@c4cgroup.co.uk.

Frequently asked questions