Broadcom ended perpetual VMware licenses in December 2023. By April 2025, they’d moved to per-core pricing with a 72-core minimum per product. Customer-reported price increases range from roughly 2x for mid-market enterprises to 8x–15x for European cloud providers, with CISPE members documenting cases as high as 1,500%. The VMware Cloud Service Provider programme (the reseller channel that hosted virtualised workloads for thousands of European organisations) was formally closed on 26 January 2026, with all transactions required to complete by 31 March 2026.
If you’re running VMware in production at a European financial institution, you already know this. What you may not have worked out yet is that the exit conversation isn’t optional anymore. DORA Article 28 requires documented, tested exit strategies for critical ICT dependencies. The EU Data Act, in force since September 2025, gives you a statutory right to switch providers on two months’ written notice. What used to be an operational inconvenience is now a regulatory expectation.
This is a guide for the team that’s decided to move and needs to figure out what to move to.
Why the Regulatory Context Changes Everything
A few years ago, “VMware migration” was a cost conversation. You’d weigh licensing savings against migration complexity and usually end up deferring. The business case rarely closed.
That calculation has shifted. DORA Article 28 requires financial entities to establish comprehensive, documented exit strategies for all third-party ICT providers supporting critical functions. Not just drafted. Tested. The ECB Guide on Outsourcing Cloud Services, published July 2025, specifies that exit plans should define roles, responsibilities, and costs before systems go live, and recommends maintaining a list of qualified alternative providers. “We’d probably move to Azure” with no documented runbook doesn’t satisfy this.
There’s also the CTPP designation process. VMware/Broadcom isn’t formally on the critical third-party provider list yet, but the first designations landed in November 2025 and the criteria are broad. If your core workloads depend on VMware, supervisory scrutiny of your exit planning is likely coming regardless.
The EU Data Act adds something useful: enforceability. You now have a statutory right to exit any cloud or IaaS provider with two months’ written notice, a 30-day transition period, and zero switching charges from January 2027 onwards. Use that leverage in your current Broadcom renewal negotiations while you build your target architecture.
Three Realistic Exit Paths
Three platforms are worth considering for an EU financial services migration: Proxmox VE, OpenStack on an EU operator, and KubeVirt on sovereign Kubernetes. Each suits a different organisation and a different workload profile. None of them is perfect.
Nutanix will come up in these conversations. It solves the Broadcom pricing problem without solving the sovereignty one: it’s US-incorporated and its management plane sits outside EU jurisdiction. Worth knowing upfront so it doesn’t derail the platform selection conversation.
Proxmox VE is where most mid-market teams will land, and it’s where I’d point a CTO who wants the most practical path out.
Proxmox Server Solutions GmbH is an Austrian company, founded 2005, privately owned with no VC backing. The hypervisor is open-source under AGPLv3. The cheapest tier that gives you access to the enterprise repository (Community) is EUR 115 per CPU socket per year; the Basic tier with professional support tickets is EUR 355; Premium is EUR 1,060. Without a subscription the software is genuinely free, including all features. Compare that to Broadcom’s current pricing and the maths aren’t subtle.
Feature parity with vSphere is good for most workloads: KVM hypervisor, LXC containers, HA clustering, live migration, Ceph and ZFS storage integration. The gap shows up in network virtualisation (no NSX equivalent; you’ll need OVN or similar), and the ecosystem of certified integrators is smaller than VMware’s. If you have unusual custom vSphere plugins, do the dependency mapping before committing.
From a sovereignty standpoint, Proxmox deployed in an EU data centre with EU operator support gets you to SEAL-2 or SEAL-3, depending on how you handle key management and operational control. The legal jurisdiction is clear: Austrian law, GDPR-compliant, no US-entity exposure. That’s a meaningful step up from VMware/Broadcom’s current SEAL-0/1 posture.
Migration tooling exists and works. Coriolis, from CloudBase Solutions, handles agentless live migration from vSphere to Proxmox. The PoC phase typically takes 8-12 weeks. Don’t skip it.
OpenStack on an EU operator is the right call if you need cloud-scale infrastructure and have (or can hire) dedicated ops expertise.
The OpenStack project is mature: launched 2012, now governed under the OpenInfra Foundation (which joined the Linux Foundation in March 2025). The deployment complexity is real, and there’s no point pretending otherwise. Self-managed OpenStack deployments fail regularly. The day-2 operations burden (patch cycles, upgrade paths, the dependency graph) requires a team that does this as a specialism, not a side activity.
The good news for EU financial services is that you don’t have to self-manage. Open Telekom Cloud (T-Systems, Germany) and OVHcloud (France, with EU data centre expansion) both offer managed OpenStack at scale, aligned with GAIA-X and GDPR. Both support SEAL-3 assurance through EU legal entity structures and EU-only data residency. If your regulatory posture requires a certified EU-sovereign provider, this is your path.
The licence line against Broadcom’s per-core pricing will come out far lower on paper, but OpenStack’s operational overhead (internal staffing or MSP support contracts) is typically higher than Proxmox’s. Build your TCO from your own staffing rates before assuming the savings are as clean as the licence delta suggests. Published OpenStack-vs-VMware comparisons disagree on the net, and most of the swing sits in ops cost, not licence cost.
KubeVirt is the right answer for a specific kind of organisation: one that’s already invested in Kubernetes and wants a unified platform for mixed VM and container workloads.
KubeVirt extends Kubernetes to run VMs as native resources. It’s CNCF-governed (incubating since 2022, applying for graduation as of late 2025), with Red Hat and IBM as founding contributors but community governance. According to Spectro Cloud’s 2025 State of Production Kubernetes Report, around a quarter of Kubernetes shops are now running it in production.
Here’s an honest limitation: KubeVirt’s financial services adoption is still early. The primary documented adopters are telco, gaming, and SaaS operators. The technology is production-ready; the financial services track record is thin. If you’re a cloud-native fintech with a Kubernetes platform team already in place, it’s worth a serious PoC. If you’re a traditional bank running a VM-first estate, the combined operational complexity of Kubernetes and KubeVirt together is probably not your first step out of VMware.
Sovereignty-wise, KubeVirt on EU-sovereign Kubernetes (Scaleway, OVHcloud Managed Kubernetes) targets SEAL-3, inheriting the sovereignty posture of the underlying platform.
Timelines: The Number Nobody Says Out Loud
The migration industry has a habit of publishing optimistic timelines and then quietly extending them in the project plan.
The technical migration may complete in five or six months. Dual-platform burn-in, staff training, and regulatory validation add another six to twelve. There are always undiscovered application dependencies. Always.
Real-world data tells a different story than vendor materials. For a small estate (under 100 VMs, low application complexity, dedicated team), expect 12-18 months rather than the 6-12 you’ll see in brochures. Medium estates (100-1,000 VMs) run closer to 24-36 months. Hidden integrations surface during execution. Plan for 3-4 migration waves, each with its own PoC and validation cycle. Regulatory checkpoints add 2-4 weeks each, and they’re non-negotiable in a supervised financial entity.
Large estates above 1,000 VMs should budget for 36-48 months. No honest way to shortcut that. Large financial institution estates carry legacy application dependencies that no automated discovery tool fully maps, and each wave of critical workloads requires supervisory sign-off.
The single biggest timeline killer is inadequate assessment. Teams spend 2-3 weeks on discovery, find 80% of the dependencies, and start migrating. The other 20% surfaces over 18 months in the form of broken authentication flows, silent failures in reporting pipelines, and custom VMware integrations nobody documented. Spend 6-8 weeks on assessment. Use automated tools (Faddom and CloudIQ work well) and manual interviews with application owners. The PoC will be faster and the migration waves will be cleaner.
A Concrete Scenario
A European payments fintech with around 400 VMs across vSphere clusters (card processing, reporting, and internal tooling) decided to migrate to Proxmox after the Broadcom repricing hit their renewal. Their DORA compliance review had already flagged the lack of a documented exit strategy.
They ran a 10-week assessment (longer than planned: the reporting pipeline had 14 undiscovered integrations with the vSphere management plane) and a 12-week PoC on a 30-VM representative slice. Proxmox met the bar for their workloads. They chose OVHcloud as their EU operator for the Proxmox clusters to reach SEAL-3 on the transaction processing layer.
Three migration waves over 18 months handled the non-critical workloads, then the reporting layer, then card processing last. The dual-platform period ran 14 months (painful on licensing, necessary for rollback confidence). Total timeline from decision to VMware decommission: 26 months.
Not fast. But the exit strategy documentation produced during the migration served directly as their DORA Article 28 artefact. The regulator asked for it in the following year’s audit. It was ready.
SEAL-Level Summary
| Platform | Legal Jurisdiction | Operational Control | SEAL Assessment |
|---|---|---|---|
| VMware / Broadcom | US (Delaware) | Low: US-controlled proprietary stack | SEAL-0/1 |
| Nutanix | US (Delaware) | Medium: on-prem but US management plane | SEAL-1 |
| Proxmox VE (EU data centre) | Austria / EU | High: open-source, customer-controlled | SEAL-2/3 |
| OpenStack on EU operator (OVHcloud, T-Systems) | France / Germany | High: EU legal entity, EU operations | SEAL-3 |
| KubeVirt on EU-sovereign K8s | EU (operator-dependent) | High: open-source, EU operator | SEAL-3 |
These SEAL assessments are analytical, not certified. The framework maps regulatory jurisdiction, operational control, and data residency to sovereignty levels. Use it as a decision tool, not a compliance certificate.
Where to Start
If you haven’t done a formal assessment yet, that’s step one. Map every workload to its VMware dependencies, classify by criticality, and identify the hidden integrations before planning anything else. The assessment output doubles as the starting point for your DORA exit strategy documentation: you’re building both artefacts simultaneously.
From there, the platform decision usually follows from three questions.
Do you have an in-house Kubernetes platform team? If yes, evaluate KubeVirt: it gives you a unified VM and container platform. If no, Kubernetes isn’t the starting point.
Do you need cloud-scale IaaS (hundreds of VMs, multi-region, managed service)? If yes, OpenStack on an EU operator (OVHcloud or T-Systems) is your path to SEAL-3 with managed operations. If no, Proxmox is simpler and cheaper.
Is your primary driver cost, sovereignty, or both? Proxmox is the best answer for cost. OpenStack on a GAIA-X-aligned EU operator is the best answer for sovereignty. KubeVirt is the best answer if your future is Kubernetes-first regardless.
One thing worth doing now, regardless of timeline: invoke your EU Data Act switching rights in your next Broadcom contract negotiation. You have statutory rights to exit. Document them. Use them as leverage on pricing. The migration will take time; the negotiating position doesn’t have to wait.
This article discusses DORA compliance implications at an architectural level. It is not legal advice. Specific obligations under DORA vary by entity classification and require review by qualified legal counsel.