Since Broadcom closed its VMware acquisition, the calculus for running virtualised infrastructure has changed. Perpetual licenses are gone, the portfolio has collapsed into a handful of subscription bundles, and pricing has moved to a per-core model. Renewal quotes have widely come back 2x to 5x higher than what teams paid before. For many CTOs and architects across Europe, the question stopped being “should we look at alternatives” and became “what do we move to, and in what order”.
This is a playbook, not a sales pitch. We are an engineering consultancy, not a cloud provider, so we have no platform to push you onto. The goal here is to give you the concepts, the open standards, and an honest map of the options so you can make a decision that fits your stack.
Why teams are leaving VMware
The drivers are consistent across the organisations we talk to:
- Cost. Per-core licensing punishes high-density hosts. A two-socket server with two 16-core CPUs that used to need two CPU licenses now counts as 64 cores. Combined with bundle consolidation, many renewals land far above prior spend.
- Bundling. vSphere, vSAN, NSX, and the Aria suite are now packaged into large subscriptions like VMware Cloud Foundation (VCF) and vSphere Foundation (VVF). If you only used vSphere, you may be paying for capabilities you never deploy.
- Lock-in and end-of-support pressure. vSphere 7 reached end of general support in October 2025, and vSphere 8 is scheduled for October 2027. Perpetual licenses keep running, but without patches and support the clock is real.
- Ecosystem disruption. Partner and Cloud Service Provider program changes (the VCSP model moved to invite-only in early 2026) have pushed some managed-hosting relationships into renegotiation.
None of this means you must rip everything out next quarter. It means you should know your options and have a credible exit path.
There is no single VMware replacement
This is the most important point in the whole playbook. VMware bundled compute virtualisation, storage (vSAN), networking (NSX), and management (vCenter, Aria) into one stack. No open-source project replaces all of that with a single product. The right move is to map options to workloads, lead with open standards (KVM, QEMU, libvirt, Ceph, OVN/Open vSwitch, the OCI and Kubernetes APIs), and choose tools that fit each layer.
Here is the broad landscape, grouped by where each option shines. Treat these as representative, not exhaustive, and not as endorsements of one tool over another.
VM-first platforms (closest to a vCenter-style experience)
- Proxmox VE - KVM plus LXC, with built-in clustering, live migration, and Ceph integration. Strong fit for SMB-to-midmarket and straightforward on-prem virtualisation where simplicity matters.
- oVirt - the upstream of the former Red Hat Virtualization. Now community-maintained after Red Hat stepped back, and the basis of products like Oracle Linux Virtualization Manager. A familiar datacentre/cluster/host model for teams that liked vCenter’s structure.
- Harvester - SUSE’s open-source hyperconverged platform built on Kubernetes, KubeVirt, and Longhorn. Gives you a VM-centric UI while sitting on cloud-native plumbing underneath.
Private-cloud platforms (IaaS with multi-tenancy and self-service)
- OpenStack - the most capable and most modular option, with separate projects for compute (Nova), networking (Neutron, typically OVN), storage (Cinder, Swift), and identity (Keystone). Excellent at scale, but it is genuinely complex and rewards a skilled operations team.
- Apache CloudStack - an integrated, opinionated IaaS that is quicker to stand up than OpenStack, with multi-hypervisor support and mature networking. Popular with service providers and telcos.
- OpenNebula - lightweight and pragmatic, well suited to edge, hybrid, and small-to-medium private clouds where you want orchestration without OpenStack’s operational weight.
Kubernetes-native paths
If your roadmap is already cloud-native, you can converge VMs and containers on one control plane:
- KubeVirt - runs VMs as Kubernetes resources. It is a CNCF project (entering graduation review in late 2025) with a growing adopter base, and is the engine behind several commercial virtualisation products.
- Cluster API - declarative provisioning and lifecycle management for Kubernetes clusters, often paired with KubeVirt or bare metal for a cluster-as-a-service model.
For bulk VM migration into the Kubernetes world, the open-source Forklift project (the basis of Red Hat’s Migration Toolkit for Virtualization) connects to vCenter, inventories VMs, converts disks, and performs cold or warm migrations.
How to choose
Start from your workloads and your team, not from a product shortlist. A few questions that consistently separate the good fits from the painful ones:
- What are you actually running? Mostly long-lived Windows and Linux VMs? A VM-first platform is the path of least resistance. Already containerising? A Kubernetes-native path may consolidate two stacks into one.
- Do you need multi-tenancy and self-service? If yes, you are in private-cloud territory (OpenStack, CloudStack, OpenNebula) rather than a single-tenant hypervisor manager.
- What is your operational maturity? OpenStack’s power comes with real day-2 cost. Be honest about whether you have - or will hire, or will outsource - the skills to run it.
- Which VMware features are load-bearing? vMotion, HA, DRS, vSAN, NSX micro-segmentation, and Site Recovery Manager all have open-source equivalents, but they rarely map one-to-one. Inventory the features you truly depend on, not the ones you licensed.
- Storage and networking reality. Most open-source paths lean on Ceph for storage and OVN/Open vSwitch for networking. Your existing SAN, fabric, and segmentation policies will need a deliberate design, not a copy-paste.
A phased migration approach
Migrations fail when they are treated as a one-shot cutover. Sequence the work and reduce risk at each gate.
1. Assess
Build a complete inventory: VMs, dependencies, storage layout, network and security policies, and licensing exposure with dates. Score each workload by downtime tolerance, complexity, and compliance sensitivity. The output is a ranked migration backlog, not a spreadsheet that gets stale.
2. Design
Choose the target platform(s) per workload group and design the storage and network architecture explicitly. This is where you map NSX policies to OVN security groups, vSAN to Ceph, and DRS-style placement to your new scheduler. Decide your migration mechanics here too: cold vs warm migration, tooling, and rollback.
3. Pilot
Stand up the target in a lab and migrate 10-20% of production-equivalent workloads. Measure performance parity, validate HA failover, test backup and restore, and exercise your security policies. A two-to-four-week pilot surfaces the surprises while they are cheap.
4. Migrate
Move in waves, sequenced by risk, keeping per-wave production impact small (a 10-15% ceiling is a sensible rule of thumb). Start with stateless dev/test, then web tiers, then databases and mission-critical systems. Keep the old environment as a rollback target until each wave is validated.
5. Operate
A new platform needs new runbooks, monitoring, patching cadence, capacity planning, and DR procedures. Plan for skills transfer so the team owns day-2 operations rather than depending indefinitely on whoever ran the migration.
Pitfalls to plan around
- The 10% problem. A small set of VMware-only applications creates most of the migration drag. Identify them early; they will dictate your timeline.
- Networking is harder than compute. vSwitches, port groups, and NSX policies do not transfer directly. VLAN mismatches and policy recreation are a top cause of extended downtime.
- DR testing takes months, not weeks. Do not discover this near go-live. Engage compliance and DR stakeholders in the design phase.
- Underestimating day-2. The license you cancel is replaced by operational responsibility. Budget for skills, automation, and observability.
- Tool monogamy. Resist standardising on one platform for everything before the pilot proves it. Mixed estates are normal and often optimal.
The EU sovereignty upside
For European organisations, and German ones in particular, this migration is also a sovereignty opportunity. Running open-source infrastructure on EU-hosted capacity removes two layers of external dependency at once: the software is not controlled by a single foreign vendor’s roadmap or pricing, and the data stays under EU jurisdiction. That combination - open source plus EU data residency - is exactly what frameworks behind the recent Franco-German digital-sovereignty push and the European Commission’s Cloud Sovereignty efforts are reaching for.
The strategic point is leverage. Open standards mean your workloads stay portable, you negotiate from a position of choice rather than dependency, and your compliance posture (GDPR, sectoral data rules) is built in rather than bolted on. Sovereignty here is a capability you design for, not a checkbox.
FAQ
Is Proxmox a real replacement for VMware?
For VM-first environments, yes. Proxmox VE covers clustering, live migration, HA, and Ceph-backed storage. It is not a full private-cloud IaaS, so if you need multi-tenant self-service, look at OpenStack, CloudStack, or OpenNebula instead.
Proxmox vs VMware - what is the biggest practical difference?
Architecture and ecosystem. VMware offers a tightly integrated, single-vendor stack; Proxmox assembles open components (KVM, LXC, Ceph). You trade vendor integration and enterprise support contracts for cost control, no per-core licensing, and no lock-in.
How long does a VMware migration take?
It depends on estate size and the share of VMware-only workloads, but think in quarters, not weeks. A phased plan with a real pilot and wave-based cutover is what keeps risk and downtime contained.
Do we have to move everything off VMware at once?
No. Perpetual licenses keep running without support, which buys time. Most teams migrate in waves and keep a shrinking VMware footprint during the transition.
Can VMs and containers run on one platform?
Yes. KubeVirt runs VMs as Kubernetes objects, letting you converge both on a single control plane. It suits teams already invested in cloud-native operations.
Where Rapid Solutions fits
We are a vendor-neutral engineering consultancy with offices in Amsterdam and Dubai. We do not sell a platform, so our recommendation is driven by your workloads, your team, and your compliance needs - not by what we have to monetise. We help with the assessment, the target design, the pilot, the wave-based migration, and the day-2 operating model, with an open-source-first and sovereign-by-design approach throughout.
If you are facing a VMware renewal or planning an exit, contact Rapid Solutions and we will help you build a migration path that fits the stack you actually run.