Vaše VMware smlouva končí v 2026. Co dál — bez úniku do neznáma

Většina českých a slovenských enterprise má od Broadcomu pod stromečkem jedno: novou VMware cenovku. A jestli jste to ještě neřešili, máte 12–18 měsíců, než vám to začne ničit rozpočet. Tady je, co reálně znamenají alternativy — ne v marketingu, ale v praxi.

Co se reálně změnilo

Rekapitulace pro ty, kdo to odkládali: Broadcom po akvizici VMware v roce 2024 zrušil perpetuální licence, přešel na subscription tiers a zbytek už znáte — licenční náklady pro mid-market a enterprise vzrostly řádově o desítky až stovky procent. Nejsou to řeči z LinkedInu, je to realita v rozpočtech, které právě teď procházejí CFO schvalováním na rok 2026.

Důležité je, že tato změna není něco, co „přejde". Obnova tříletých smluv, které byly podepsané před akvizicí, padá právě teď a v roce 2027. Pro velkou část CZ/SK trhu je tohle moment rozhodnutí.

Tři reálné alternativy, které dnes dávají smysl

Proxmox VE

Nejčastější první nápad. Levné, open-source, aktivní komunita. Funguje dobře pro menší prostředí a týmy, které jsou zvyklé řešit věci svépomocí. Limity se ukážou, jakmile narazíte na enterprise požadavky — certifikovaný support s SLA pro mission-critical workloady, integraci s podnikovým SSO, předpokládaný roadmap na 5 let, auditní compliance. U středního podniku s 200+ VM a produkčními SLA to začíná skřípat.

Hyper-V / Windows Server

Rozumná volba pro Windows-heavy shopy, kteří už mají Microsoft Enterprise Agreement. Licenčně často nulový přírůstek, funkčně pokrývá většinu běžných scénářů. Problém je technologický lock-in na Microsoft stack a omezená cesta k cloud-native architektuře. Krok do strany, ne dopředu.

Red Hat OpenShift Virtualization

Jediná alternativa z tří, která infrastrukturu posouvá dopředu, ne do strany. Proč: VM a kontejnery běží na jedné platformě (postavené na KubeVirt), takže migrace z VMware není jen výměna hypervizoru — je to krok k unifikované platformě, na které za 2–3 roky provozujete i cloud-native aplikace. Microsoft Ignite 2025 navíc potvrdil GA OpenShift Virtualization na Azure Red Hat OpenShift, takže podporovaná cesta do Azure je otevřená.

Proč OpenShift Virtualization + Ansible z pohledu dlouhodobé architektury

Klíčová vlastnost, která dělá rozdíl na papíře i v provozu: nepotřebujete udržovat dva paralelní světy. Dnes většina firem provozuje jednu platformu pro VM (VMware) a druhou pro kontejnery (obvykle OpenShift nebo jiný Kubernetes). Dva operační týmy, dvě sady skillů, dvě upgrade roadmapy, dva support contracty. OpenShift Virtualization to spojuje — stejný cluster, stejný API, stejný operační model.

Red Hat zveřejnil 15. dubna referenční architekturu nazvanou Proximity automation, která popisuje, jak řídit VM provoz přes Ansible Automation Platform z cloudového management clusteru bez otevírání SSH kanálů do on-premise. To je typ pattern, který VMware+vRA dnes nabízí, ale v OpenShift ekosystému zapadá přirozeněji a bez licenčního overheadu.

Pro enterprise je to technicky i politicky čistší — jeden vendor, jedna podpora, jedna certifikační cesta pro tým.

---
# Přesun VMware VM do OpenShift Virtualization přes MTV (Migration Toolkit
# for Virtualization). Spouštěno z AAP — žádný SSH do on-prem, jen API.
- name: Migrate workload from vSphere to OpenShift Virtualization
  hosts: localhost
  tasks:
    - name: Vytvoř migration plan (mapuje síť + storage 1:1)
      redhat.openshift_virtualization.migration_plan:
        name: "wave-03-billing"
        source_provider: "vsphere-prod"      # registrováno v MTV
        target_namespace: "billing-vms"
        vms: "{{ batch_vms }}"               # 10–20 VM na vlnu
        warm: true                           # warm migrace = minimální downtime
    - name: Spusť migraci a čekej na dokončení
      redhat.openshift_virtualization.migration:
        plan: "wave-03-billing"
        state: started
      register: result
    - name: Ověř, že všechny VM běží
      ansible.builtin.assert:
        that: result.migrated | length == batch_vms | length

Klíčový bod: warm migrace drží VM běžící až do finálního cutoveru — downtime je v minutách, ne hodinách. Detaily v dokumentaci MTV.

Reality check: tři věci, které se vám nikdo neřekne v prvním callu

• Není to zadarmo. Licenční poplatek za OpenShift + AAP není nulový. Posouváte náklad z VMware smlouvy na Red Hat smlouvu. Úspora přichází z dlouhodobé TCO — méně operačních týmů, méně nástrojů, méně integrací — ne z cenovky v prvním roce.
• Migrační projekt trvá 6–18 měsíců. Záleží na velikosti estate, kvalitě dokumentace současného prostředí a ochotě týmu učit se. Pro 500 VM počítejte s rokem. Pro 2 000 VM a více s dvěma lety, rozděleno do vln.
• Potřebujete Kubernetes-savvy tým, nebo partnera. VMware admin, který neotevřel terminál pro kubectl, se s OpenShift Virtualization sám nenaučí za víkend. Je to kulturní přechod, ne jen technický.

Reálný timeline pro rozhodnutí

Pokud smlouva končí v 2027, plánujte takto:

Měsíce 1–2 · Proof-of-concept
   ↳ Pár nenasazených workloadů na malém OpenShift clusteru.
   ↳ Odpověď na otázku, jestli vám to technicky sedí.

Měsíce 3–5 · Pilotní migrace
   ↳ 10–20 produkčních VM do dedikovaného clusteru.
   ↳ Validace provozního modelu, ladění Ansible playbooků, trénink týmu.

Měsíce 6–12 · Migrace v dávkách
   ↳ Ne „big bang" — systematické vlny podle aplikačních clusterů.
   ↳ Paralelní provoz s VMware, postupný odchod.

Měsíc 12+ · Konsolidace a optimalizace
   ↳ Teď teprve vidíte reálnou TCO.

Kdo má obnovu smlouvy v 2027 a čeká do 2027 s PoC, zmešká okno. Reálně začít je potřeba dnes, ne „po Vánocích".

Závěr

VMware migrace není technické rozhodnutí. Je to strategické rozhodnutí o tom, jak bude vaše infrastruktura vypadat v roce 2030 — a jestli ji budete mít pod kontrolou, nebo ji budete jen provozovat.