The Hypervisor Exit Is an Application Problem: What the VMware Migration Wave Is Really Costing Engineering Teams

Why Is Every European CIO Suddenly Running a Virtualization Project?

For most of the last fifteen years, the hypervisor was the least interesting layer in the stack. It worked, the licence renewed itself, and no engineering leader spent a planning cycle thinking about it. That ended when Broadcom completed its acquisition of VMware, retired perpetual licensing and standalone support, and folded the product line into subscription bundles priced on a different scale entirely.

The numbers that followed were not marginal adjustments. AT&T sued Broadcom over licensing changes it said would raise its costs by 1,050%, a case the two parties later settled. In Europe the picture was worse: CISPE, the trade body for European cloud infrastructure providers, told the European Commission that its members had seen price increases between 800% and 1,500%, and characterised the merger clearance as a blank cheque to raise prices and lock customers in. Its members are still pushing the EU General Court to annul the deal outright.

Then came the decision that turned a budget argument into an architecture deadline. In January 2026 Broadcom stopped renewing contracts under its Advantage Partner Program for VMware Cloud Service Providers, moving to an invite-only model. The Register reported that partner contracts closed on 26 January with a 31 March cut-off for open opportunities, and that in the United States roughly nineteen VCSP providers remain from what had been thousands. Hundreds of European providers were affected, and one of them described it not as partner management but as forced consolidation.

That distinction matters more than the percentages. A price rise is something a CFO negotiates. A hosting provider losing its right to resell the platform your production estate runs on is a change your engineering team has to absorb on someone else's calendar. Thousands of European companies did not decide to run a virtualization migration this year. They were handed one.

What Does Leaving Actually Cost, and How Long Does It Take?

The market has already answered the question of whether people will go. Gartner's guidance, reported in September 2025, forecasts that more than a third of workloads currently running on VMware will run somewhere else by 2028, driven by cost pressure pushing the large majority of enterprise VMware clients to move a substantial share of their estate. That is not a fringe migration. That is the default assumption for the next three planning cycles.

The cost of getting out is where the conversation gets uncomfortable, because it is charged per virtual machine rather than per site. Gartner's assessment, summarised by ITdaily, is blunt about this: migration is expensive and is not getting cheaper, and for large estates it consumes a year or two. Typical migration service pricing sits in the region of several hundred to a thousand euros per VM for straightforward moves, with complex workloads running far higher and full refactors into native cloud services costing several thousand each. Multiply that by an estate of four thousand VMs and the migration is a larger line item than the licence renewal that triggered it.

Real programmes bear that out. At Red Hat Summit 2026, Cleveland Clinic described an environment of more than 10,000 VMs, of which 450 had moved, with a 19-month runway to complete the migration before its next renewal date and an expected halving of total cost of ownership against staying. TechTarget's coverage of the same event also recorded FedHIVE moving 100 VMs in about six weeks after facing a ninefold cost increase at renewal, and Emirates NBD moving more than 9,000 VMs at a rate of up to 200 machines per night.

Read those three side by side and the shape of the problem appears. A hundred VMs is six weeks. Ten thousand VMs is not a hundred times six weeks, because the per-VM effort is not the constraint. The constraint is how many distinct applications sit on top of those VMs, how well anyone understands the relationships between them, and how much verification capacity you can bring to bear on proving that a wave landed without breaking something three services away.

Why the Hard Part Sits Above the Hypervisor

Almost every VMware exit gets scoped as an infrastructure decision. A committee compares Proxmox, Nutanix, Hyper-V, OpenShift Virtualization and the public cloud, runs a bake-off, picks a platform, and books a budget. That work is real, and it is roughly a quarter of the programme. The other three quarters are application engineering, and they are usually discovered after the budget is fixed.

The evidence is consistent about where these projects fail. Analysis citing IDC's wave-planning research reports that 31% of migrations miss their planned timeline and 18% have to roll back at least some workloads, and attributes both to workloads sequenced without a clear picture of their dependencies. The same source puts the share of migrations that overrun on dependencies nobody mapped at roughly 73%.

This is not a documentation failure in the abstract. It is specific and it is boring. A virtual machine is not an application. An application is a set of virtual machines, plus the firewall rules that let them talk, plus the storage semantics they assume, plus a scheduled job on a fourth machine that nobody has looked at since the person who wrote it left, plus a hard-coded IP in a config file that only matters during failover. Moving the VM is a solved problem with good tooling. Moving the application means reconstructing all of that from a live system, in production, without the original authors.

The teams that land these programmes on time are the ones that treat the dependency inventory as the first deliverable rather than a planning artefact, and that sort every workload into three honest buckets before wave one: lift-and-shift candidates, refactor candidates, and special-handling cases with hardware passthrough, vGPU, NSX-specific networking or storage features that exist on exactly one platform. The third bucket is always larger than the first estimate, and it is the bucket that decides the schedule.

A Field Guide to What Actually Breaks

The failure modes in a hypervisor migration are unglamorous, well known to anyone who has done one, and almost never in the initial scope. It is worth naming them concretely, because each one is a work package with an owner and an estimate, and a programme plan that omits them is not a plan.

Network policy is first and worst. Port groups, distributed switches and NSX distributed firewall rules do not translate automatically to any target platform. Gartner's own migration guidance on NSX treats this as a re-implementation exercise rather than a conversion, and in practice engineers rebuild micro-segmentation rules by hand against a policy set that has accreted for a decade and that nobody has audited. VLAN mismatches and half-recreated policies are the single most common cause of an extended cutover window.

Storage is second. Multi-hypervisor migration guidance notes that native Microsoft tooling cannot directly convert VMs resident on vSAN, and that vSAN snapshots do not carry across, so point-in-time recovery has to be re-established with cloud-native or platform-native backups before cutover rather than after. Any team that plans to rely on its existing snapshot chain as the rollback mechanism is planning to have no rollback mechanism.

Then comes everything your engineers actually wrote. Terraform modules built on the vSphere provider have to be rewritten against a different provider with different resource semantics, which means every environment definition, every module, and every pipeline that consumes them. Backup and disaster recovery runbooks have to be re-proven, not just re-pointed, and the recovery time objectives your compliance documentation promises have to be re-measured on the new platform. Monitoring dashboards and alert rules that scrape vCenter go dark on cutover day. Applications that call vSphere APIs directly for provisioning or inventory need new integrations. Licensing that is pinned to a virtual machine UUID or MAC address needs re-issuing by a vendor whose support desk has never heard of your target platform. Build agents and CI runners hosted on the old estate have to move without stopping delivery of the product the migration is meant to protect.

None of these are research problems. Every one has a known solution and a definable finish line. That is exactly why they get deferred: work that is understood but tedious loses every prioritisation argument against a feature with a customer attached, right up to the point where a renewal date makes it non-negotiable.

The Landing Zones, and What Each One Asks of Your Engineers

There is no universally correct target, but the options differ far more in what they demand of your people than in what they cost per socket. That is the axis most bake-offs under-weight.

The like-for-like KVM route, principally Proxmox VE and XCP-ng, is the cheapest and the least disruptive to operational habit. Your administrators keep thinking in terms of virtual machines, datastores and clusters, and the concepts map closely enough that re-skilling is measured in weeks. The trade is that you inherit an ecosystem with thinner enterprise tooling around backup, governance and multi-site orchestration, and you take on more integration work yourself. Veeam adding Proxmox support was the change that made this route viable for regulated estates rather than lab environments.

The commercial HCI route, chiefly Nutanix AHV or Microsoft Hyper-V, is the closest thing to a straight swap with a vendor behind it. It costs more than the open-source path and less than staying, and it preserves the operating model almost entirely. For a Windows-centric estate with a small platform team and no appetite for a re-architecture, it is frequently the correct and boring answer.

The Kubernetes-native route is the one with the most momentum and the steepest conceptual cost. Red Hat reported that virtual machines running on OpenShift Virtualization grew 417% in 2025, with clusters running VMs up 93% and accounts up 70%, alongside deployments at Telenet Business, which has moved nearly 200 of roughly 1,000 VMs onto bare-metal OpenShift across two Belgian data centres, and at NASA's Jet Propulsion Laboratory. Emirates NBD ended up with all but three of its 350 applications running on OpenShift Virtualization or OpenShift Container Platform. Ali Rey of Emirates NBD put the honest caveat plainly in TechTarget's report from Red Hat Summit: going to KubeVirt is more of a re-platforming, and the thinking about it is quite different. You are not buying a hypervisor. You are asking your virtualization team to become a platform engineering team, which is a hiring and training decision as much as a technical one.

The public cloud route deserves one clarification, because it is routinely mis-costed. Lifting VMs into a hyperscaler's VMware-compatible service preserves your operating model but reproduces much of the licence exposure you are trying to escape. Refactoring into native compute removes it, but at a per-VM cost several times the like-for-like alternatives, and with application changes that are indistinguishable from a modernization project. That is a defensible choice. It is not a migration, and calling it one is how eighteen-month programmes become four-year ones.

The Sovereignty Dividend Nobody Planned For

There is a second reason European boards are paying attention to a virtualization project, and it has nothing to do with per-core pricing. The same estate rebuild that the licensing shock forced is the cheapest opportunity in a decade to make data residency and platform portability structural rather than contractual.

The starting position is lopsided. Around 72% of cloud services in Europe are delivered by the three US hyperscalers, and up to 90% of European data sits on infrastructure outside EU control. For most organisations that was a defensible position when the alternative was inconvenient and expensive. The Broadcom episode changed the risk calculation in a way that generalises: the thing that hurt was not a technical failure but a commercial decision taken elsewhere, applied to a dependency that had been treated as permanent.

The practical consequence is that portability is now worth designing for even when you do not intend to use it. If your target platform is open-source KVM or Kubernetes-based, your workloads can move again without another eighteen-month programme. If your infrastructure-as-code is provider-agnostic where it can be and cleanly isolated where it cannot, the next forced move is a quarter rather than a year. If your data residency is enforced by where the cluster physically is rather than by a clause in a contract, it survives the contract being renegotiated.

This connects directly to obligations that are already landing. Cloud switching and exit requirements under the EU Data Act bite in January 2027, and we covered what that means for architecture in our piece on engineering for cloud exit. The broader sovereignty picture, including what the Cloud and AI Development Act asks of engineering teams, is set out in our CADA analysis. A team that is already rebuilding its platform layer can satisfy a good deal of both as a by-product. A team that finishes the migration first and reads the regulations afterwards will do the work twice.

Who Is Actually Going to Do This Work?

Here is the question that decides most of these programmes, and it almost never appears on the bake-off scorecard: which engineers are doing it, and what are they not doing while they do?

The people qualified to run a hypervisor migration are the same people who run your platform. They own the CI/CD pipelines, the observability stack, the Kubernetes clusters and the on-call rotation. They are also, in most organisations, four to eight people with no slack in their quarter. Handing them an 18-to-36-month migration produces one of two outcomes. Either the roadmap freezes while the platform team disappears into the migration, which is a strategic cost nobody writes down, or the migration proceeds at whatever pace is left over after the roadmap, which is how a two-year programme meets a renewal date it cannot meet.

The usual escape is a large systems-integration contract priced per VM. That works, in the sense that the VMs move. What it tends not to leave behind is knowledge. The engineers who reconstructed your firewall policy and rewrote your Terraform modules roll off at the end of the engagement, and eighteen months later nobody at your company can explain why a particular rule exists. Given that the whole reason you are in this position is an inherited dependency nobody examined, replacing it with an estate nobody understands is a poor trade.

The third option is to run the migration as a parallel engineering track with a dedicated team that is genuinely yours for the duration, and this is the shape of work we are built for at Stepto. We put named senior engineers in Serbia onto a programme rather than rotating individuals through a ticket queue, which matters here specifically because migration knowledge is perishable: the person who mapped a dependency in month three is the person you need in month fourteen when the wave containing it finally moves. Central European hours overlap the full European working day, which is not a nicety when the work involves cutover windows, change freezes and rollbacks that need both the team that owns the platform and the team that owns the application awake at the same time. And operating inside the EU regulatory perimeter means residency, GDPR and access control are constraints our engineers already build under rather than requirements to be retrofitted.

The work splits cleanly into engagements with countable outputs. A dependency inventory and wave plan across the estate is a well-bounded discovery project. An infrastructure-as-code rewrite against the target provider is a defined piece of engineering with a test suite at the end of it. Backup, DR and observability re-establishment is a work package with a rehearsal date. Our dedicated team, DevOps and platform engineering, and application modernization engagements are designed for exactly this: a senior-led track running alongside your product roadmap instead of consuming it, staffed by engineers you can name and who are still there when you need to ask why.

How to Scope It So It Does Not Become a Four-Year Programme

The difference between the programmes that land and the ones that drift is almost entirely in the first eight weeks, before a single virtual machine moves.

Build the dependency inventory first and treat it as the deliverable that gates everything else. Not a spreadsheet of VMs, which you already have, but a map of applications to the machines, network policies, storage semantics, scheduled jobs and external integrations they actually depend on. Sort the result into lift-and-shift, refactor, and special-handling, and accept that the special-handling bucket will be bigger than anyone wants. This is the artefact that the timeline-miss and rollback data points at, and it is the cheapest insurance in the programme.

Pick a pilot wave that is genuinely representative rather than genuinely easy. A test VM proves nothing. A production application with a database, a firewall policy, a backup schedule and a downstream consumer proves your runbook, and it surfaces the three things you did not know in a week that would otherwise have surfaced in month eleven across forty applications at once.

Prove rollback before you need it. Because vSAN snapshots do not travel and your existing recovery mechanism may not exist on the target platform, the rollback path has to be built and rehearsed as part of wave zero. A wave you cannot reverse is not a migration step, it is a bet.

Rewrite the infrastructure-as-code before the first production wave rather than after it, or you will spend the migration operating two estates by two different methods and reconciling them by hand. Budget verification capacity as an explicit line: someone has to prove each wave landed, and in an estate where the automated coverage is thin, that is people and time rather than a pipeline stage. And define done to include the decommission and the runbook. A migration that ends with the old cluster still running and the knowledge in one person's head has converted a licensing problem into an operational one.