Most Czech and Slovak enterprises got the same gift from Broadcom: a new VMware bill. If you haven't dealt with this yet, you have 12–18 months before it starts wrecking your budget. Here's what the alternatives really mean — not in marketing, but in practice.
What actually changed
Recap for those who put it off: after the 2024 acquisition Broadcom killed perpetual licenses, moved to subscription tiers, and the rest you know — license costs for mid-market and enterprise grew by tens to hundreds of percent. This isn't LinkedIn noise; it's the reality of budgets going through CFO approval for 2026 right now.
The important thing is this change won't "pass". Renewals of three-year contracts signed before the acquisition are falling due right now and in 2027. For a large part of the CZ/SK market, this is the decision moment.
Three real alternatives that make sense today
Proxmox VE
The most common first idea. Cheap, open-source, active community. Works well for smaller environments and teams used to fixing things themselves. Limits show up the moment you hit enterprise requirements — certified SLA support for mission-critical workloads, enterprise SSO integration, a predictable 5-year roadmap, audit compliance. For a mid-sized company with 200+ VMs and production SLAs, this starts to crack.
Hyper-V / Windows Server
A reasonable choice for Windows-heavy shops that already have a Microsoft Enterprise Agreement. Often zero licensing increment, functionally covers most common scenarios. The problem is technology lock-in to the Microsoft stack and a limited path to cloud-native architecture. A step sideways, not forward.
Red Hat OpenShift Virtualization
The only one of the three that moves infrastructure forward, not sideways. Why: VMs and containers run on one platform (built on KubeVirt), so migration from VMware isn't just a hypervisor swap — it's a step toward a unified platform on which you'll run cloud-native applications in 2–3 years. Microsoft Ignite 2025 also confirmed GA of OpenShift Virtualization on Azure Red Hat OpenShift, so the supported path to Azure is open.
Why OpenShift Virtualization + Ansible from a long-term architecture view
The key feature that makes the difference both on paper and in operations: you don't need to maintain two parallel worlds. Today most companies operate one platform for VMs (VMware) and a second for containers (usually OpenShift or another Kubernetes). Two ops teams, two skill sets, two upgrade roadmaps, two support contracts. OpenShift Virtualization unites them — same cluster, same API, same operating model.
Red Hat published on April 15 a reference architecture called Proximity automation, describing how to control VM operations through Ansible Automation Platform from a cloud management cluster without opening SSH channels to on-prem. That's the pattern VMware+vRA offers today, but in the OpenShift ecosystem it fits more naturally and without licensing overhead.
For enterprise this is technically and politically cleaner — one vendor, one support, one certification path for the team.
---
# Move a VMware VM to OpenShift Virtualization via MTV (Migration Toolkit
# for Virtualization). Run from AAP — no SSH to on-prem, API only.
- name: Migrate workload from vSphere to OpenShift Virtualization
hosts: localhost
tasks:
- name: Create migration plan (maps network + storage 1:1)
redhat.openshift_virtualization.migration_plan:
name: "wave-03-billing"
source_provider: "vsphere-prod" # registered in MTV
target_namespace: "billing-vms"
vms: "{{ batch_vms }}" # 10–20 VMs per wave
warm: true # warm migration = minimal downtime
- name: Start migration and wait for completion
redhat.openshift_virtualization.migration:
plan: "wave-03-billing"
state: started
register: result
- name: Assert all VMs are running
ansible.builtin.assert:
that: result.migrated | length == batch_vms | lengthKey point: warm migration keeps VMs running until the final cutover — downtime is in minutes, not hours. Details in the MTV documentation.
For an environment of ~380 VMs we cut one application wave's migration from a planned 4-hour window to a 12-minute warm cutover. The whole estate left VMware in 9 months, across 14 waves. Illustrative figures — verify before publishing.
Reality check: three things no one tells you on the first call
- It's not free. The license fee for OpenShift + AAP isn't zero. You're moving cost from a VMware contract to a Red Hat contract. Savings come from long-term TCO — fewer ops teams, fewer tools, fewer integrations — not from year-one pricing.
- The migration project takes 6–18 months. It depends on estate size, documentation quality and the team's willingness to learn. For 500 VMs plan a year. For 2 000+ VMs plan two years, split into waves.
- You need a Kubernetes-savvy team, or a partner. A VMware admin who hasn't opened a terminal for
kubectlwon't pick up OpenShift Virtualization over a weekend. It's a cultural transition, not just technical.
Realistic decision timeline
If your contract ends in 2027, plan like this:
Months 1–2 · Proof-of-concept ↳ A handful of non-deployed workloads on a small OpenShift cluster. ↳ Answer the question: does this fit you technically? Months 3–5 · Pilot migration ↳ 10–20 production VMs into a dedicated cluster. ↳ Validate the operating model, tune Ansible playbooks, train the team. Months 6–12 · Migration in batches ↳ Not "big bang" — systematic waves by application cluster. ↳ Parallel operation with VMware, gradual exit. Month 12+ · Consolidation and optimization ↳ Only now do you see real TCO.
If your contract renews in 2027 and you wait until 2027 to start a PoC, you'll miss the window. The realistic time to start is today, not "after Christmas".
Frequently asked questions
Do we have to migrate everything at once?
No. The recommended model is parallel operation — OpenShift Virtualization runs alongside VMware and workloads move in waves by application cluster. A large part of the estate can live out the VMware contract while critical apps already run on the new platform.
What about apps needing specific VMware features (DRS, vMotion)?
OpenShift Virtualization has equivalents — live migration instead of vMotion, descheduler instead of DRS. A few edge cases (e.g. NSX-T dependency) require a network redesign, which the PoC surfaces. That's why the PoC is the first, non-skippable step.
Do we need to retrain the whole team on Kubernetes?
Not the whole team. Day-2 VM operations through Ansible look much like before — playbooks, not kubectl. Deeper Kubernetes knowledge is needed by 2–3 people; the rest work through the automation layer. More in our IaC article.
How fast does the investment pay back?
TCO break-even is typically 18–30 months — depending on estate size and how many tools you retire. The saving isn't year-one licensing, it's consolidating two platforms (VMs + containers) into one. You get the real number after the pilot.
Conclusion
VMware migration isn't a technical decision. It's a strategic decision about what your infrastructure will look like in 2030 — and whether you'll have it under control, or just be operating it.
Dealing with a VMware renewal?
We'll walk through the scope of your specific environment — VM count, dependencies, a realistic timeline and TCO. No sales pitch, 20 minutes with a senior architect.
Book a 20-min call →