VMware replacement after Broadcom: a guide for service providers, banks, and sovereign clouds in 2026

After Broadcom, the VMware bill stopped being predictable. Subscription-only licensing, mandatory VCF bundling, two-to-five-times price increases on renewal, and the end of perpetual licences changed the math for every infrastructure team running VMware at scale. The result has been a documented wave of VMware replacement projects across service providers, banks, government, telecom, and AI/GPU operators evaluating how to exit VMware safely.

VMware competitors at a glance

If you’re scoping the market, here is how Cozystack compares to the most-cited alternatives to VMware:

• Cozystack (this page) — open-source, Kubernetes-native, multi-tenant. VMs + containers + databases + object storage + GPU on one platform. Best for service providers and regulated enterprises that need sovereignty and want one stack.
• Nutanix AHV — proprietary KVM-based hypervisor inside Nutanix HCI. Strong VM-only story, weak on Kubernetes-native multi-tenancy, expensive at scale.
• Proxmox VE — open-source KVM + LXC. Excellent for SMB and labs; thin on managed databases, multi-tenancy, and enterprise support model.
• Scale Computing HC3 — appliance-based hyperconverged stack. Good for ROBO/edge; closed ecosystem.
• Red Hat OpenShift Virtualization — KubeVirt-based, similar foundations to Cozystack. Heavier OpenShift footprint and Red Hat licensing model.
• OpenStack — broad, mature, large operational surface area. Best when you have a dedicated team running it.
• Microsoft Azure Stack HCI — Hyper-V on validated hardware. Locks into Microsoft licensing.
• Verge.io / Spectro Cloud / Platform9 — vendor-led KubeVirt or hyperconverged stacks; comparable to Cozystack on architecture, different commercial models.

The rest of this page goes deep on Cozystack as a Cozystack-specific VMware replacement. For a head-to-head comparison of VMware alternatives, see VMware alternatives.

Why teams replace VMware in 2026

The technical case for moving off VMware existed before Broadcom. Broadcom turned it into a board-level decision.

1. Unpredictable, subscription-only economics

VCF subscription pricing replaced perpetual licensing. Renewal quotes have come back at 2× to 5× prior spend across our pipeline. ELAs have been broken or restructured mid-term. Standalone vSphere SKUs were retired in favour of bundled VCF tiers that include components most customers do not need.

For service providers, this collapses margin: end-customer prices are sticky, licence costs are not. For banks and regulated enterprises, it breaks multi-year capex planning that was built around perpetual entitlements.

2. Vendor lock-in across the stack

VMware’s strength was integration: vSphere, vSAN, NSX, vRealize, Horizon, vCD, all assumed each other. That same integration is now the lock-in surface. Replacing one component meant rebuilding adjacent ones, so most teams stayed.

Cozystack inverts this. Each layer is an independent open-source project (KubeVirt, LINSTOR/DRBD, Cilium, Kube-OVN, KubeVirt CDI, SeaweedFS, Velero, Flux, etc.), composed by a Kubernetes operator. You can replace any layer without rewriting the rest, and you can audit every line.

3. Sovereignty, regulator pressure, and US-vendor risk

DORA (in force across the EU since January 2025) and NIS2 require demonstrable control over critical ICT third parties. For European banks, telcos, and government workloads, depending on a US-headquartered closed-source hypervisor stack is a documented operational risk.

Cozystack is open source under Apache 2.0. Your binaries, your hardware, your data plane. Ænix ships air-gap install workflows and an advisory support model that does not require direct customer-environment access.

4. Pricing isn’t the only cliff — capability is

VMware’s roadmap is now Broadcom’s roadmap. KubeVirt and the Kubernetes-native virtualization stack have a community of hundreds of contributors and a release cadence VMware can no longer match in the open. GPU support, multi-tenant tenancy, modern storage replication, GitOps-native ops — all moved to Kubernetes-native projects years ago. VMware tries to retro-fit them through Tanzu and VCF.

What Cozystack gives you instead

Cozystack is a single platform you install on bare metal. Once it’s up, you have:

• Virtual machines through KubeVirt — full KVM-based VMs with live migration (CPU only), block-storage attach, snapshots, and templates.
• Tenant Kubernetes clusters for customers who want containers — every tenant gets their own K8s, isolated.
• Managed databases — PostgreSQL, MariaDB, MongoDB, Redis, Valkey, RabbitMQ, Kafka, NATS, ClickHouse, OpenSearch, Qdrant, FoundationDB — exposed as cloud services your tenants self-provision.
• S3-compatible object storage — for backups, application data, and AI training sets.
• GPU as a service — for VMs (passthrough of whole GPUs, or NVIDIA vGPU, which requires your NVIDIA vGPU licence) and for Kubernetes pods (whole-GPU through the NVIDIA GPU Operator, fractional sharing through HAMi). NVIDIA data-centre GPUs are supported through the NVIDIA GPU Operator, which also exposes MIG partitions to pods on MIG-capable cards.
• Multi-tenant control plane — Tenant Kubernetes CRD, nested tenants, per-tenant quotas and presets.
• Observability built in — VictoriaMetrics + VictoriaLogs, open source and included.
• Backup and DR — Velero + S3 + per-database point-in-time recovery for managed services.
• Self-service portal — Cozystack Dashboard. Billing runs in your own system or through the Ænix WHMCS integration, a proprietary Ænix module (two integration modes) that is not part of open-source Cozystack.

It runs on your bare metal. No public cloud dependency. No phone-home telemetry by default.

VMware-to-Cozystack architecture mapping (vSphere alternative, ESXi alternative, vCenter alternative — all in one)

The questions every VMware admin asks first: “What replaces vSphere? What’s a real ESXi alternative? What replaces vCenter, NSX, vSAN, vCloud Director?” Here is the direct one-to-one mapping.

Two areas need redesign rather than one-for-one mapping: networking (Cilium is fundamentally different from NSX) and multi-tenancy model (Cozystack tenants are Kubernetes-native; vCD orgs are vSphere-native). For both, we run an architecture review before any migration commits.

How VMware migration actually works

Migration paths are workload-dependent. For most teams, this is the realistic sequence.

1. Discovery and assessment

We run a structured assessment of the current vSphere / VCF / vCD inventory: workload count, OS mix, vSAN / NSX dependencies, integrations (backup, identity, monitoring), and tenancy model. Output is a migration plan with workload buckets, risk flags, and timing.

2. Cozystack deployed in parallel

Cozystack is installed on new or repurposed hardware alongside the existing VMware estate. No big-bang cutover. Tenants migrate cohort by cohort.

3. VM-by-VM image migration to KubeVirt

For most VMs, migration is a disk-image copy. We use KubeVirt CDI plus a set of dedicated migration scripts we’ve built and reused across customer deployments. For Windows VMs and VMs with VMware Tools dependencies, we run an automated cleanup pass before boot on KubeVirt.

4. Network and storage cutover

Networking: VLAN mapping into Cilium, with policy parity checked against the source NSX rules. Storage: import disks into LINSTOR, validate IOPS and replication.

5. Validation and DR cutover

Each migrated workload runs in parallel on Cozystack until validated by the application owner. Backup-and-restore runbooks (Velero, PostgreSQL PITR) are written and rehearsed before final cutover; there is no SRM-style orchestrated cross-site failover.

6. VMware decommission

Licences end on their own terms. Hardware repurposed into the Cozystack cluster (we run on commodity x86 — your existing servers usually qualify).

For OpenStack, CloudStack, and Proxmox sources the same playbook applies, with different image-import and network-mapping steps.

Looking for a checklist? Use the VMware migration checklist. A structured assessment is part of the engagement — book a call to scope it.

Multi-tenancy and sovereignty

Cozystack was built for service providers first. The same model works for any organization that needs hard separation between business units.

• Tenant CRD — each tenant is a Kubernetes object. Namespaces are derived (<parent>-<name>), nested tenants are supported, quotas are enforced via Kubernetes ResourceQuotas.
• RBAC by default — tenants cannot see each other. Tenant operators get a scoped Kubernetes API.
• Air-gap install — supported and documented; works behind Harbor / Nexus / proxy patterns.
• No phone-home — telemetry is opt-in and disabled by default.
• DORA / NIS2-aligned controls — operational resilience, incident reporting, supplier-risk documentation. Architecture maps to the controls; certification, where required, is the customer’s audit process to run.
• Ænix support model — access is your choice. Advisory, runbooks and GitOps PR review need no access to your production cluster; remote access to your clusters, with your approval, and external monitoring are available on the higher support tiers. Critical for banks, telcos, and any regulated buyer who cannot expose infrastructure to a vendor.

Cozystack vs VMware — feature comparison

FAQ

Can we keep our existing hardware?

Yes — in most cases. Cozystack runs on commodity x86. The standard scenario is to deploy Cozystack on a new pod of servers, migrate workloads off VMware, then repurpose the freed VMware hardware into Cozystack as licences lapse.

How long is a typical migration?

Two numbers matter, and conflating them is how migration plans go wrong. The first production cohort typically runs in a live environment 6-12 weeks after kickoff — that is when the platform stops being a proof of concept. The whole estate takes about 8-12 months for ~100 VMs and 18-24 months for ~1,000 VMs, including planning and migration waves, after a 14- or 28-day Platform Readiness Assessment; mid-size estates fall in between, depending on dependencies. Small, flat estates land at the short end; vCD- or NSX-heavy regulated ones at the long end, run in cohorts. The driver is rarely raw migration speed — it’s regression testing and the parallel-run windows application owners will agree to.

Do you support Windows VMs?

Yes. KubeVirt runs Windows. We have an automated cleanup step that removes VMware Tools and installs the right virtio drivers before first boot on KubeVirt. Activation handling depends on your Windows licensing model — discussed during assessment.

What happens to our existing VMware operational skills?

The hypervisor concepts (VMs, snapshots, templates, networking) carry over. The control-plane shifts from vCenter to Kubernetes — for most teams this is a 4–8 week ramp with the right training and runbooks. Ænix runs the training as part of professional services.

What about VMware Cloud Foundation specifically — is the migration different?

VCF migrations are larger (more components, more integrations). The discovery phase covers SDDC Manager, Workspace ONE, Aria, NSX-T overlays, and any custom service definitions, and the assessment sizes the extra work.

What if we use vCloud Director for our customers?

vCD migration is the most common path for service providers. Tenant model maps to Cozystack Tenant CRD, service catalog maps to ApplicationDefinition, billing maps to the Ænix WHMCS integration or your own billing system. We are happy to walk through the architecture in a call.

Is GPU live migration supported?

No — industry-wide limitation, not Cozystack-specific. VMware vGPU live migration has known caveats too. For inference workloads we recommend designing for stateless restart rather than relying on GPU live migration.