Die meisten tschechischen und slowakischen Unternehmen haben von Broadcom dasselbe Geschenk bekommen: eine neue VMware-Rechnung. Wenn Sie sich noch nicht damit beschäftigt haben, bleiben Ihnen 12–18 Monate, bevor es Ihr Budget zerstört. Hier ist, was die Alternativen wirklich bedeuten — nicht im Marketing, sondern in der Praxis.
Was sich wirklich geändert hat
Kurze Zusammenfassung für alle, die es aufgeschoben haben: Nach der Übernahme 2024 hat Broadcom die unbefristeten Lizenzen abgeschafft, ist auf Subscription-Tiers umgestiegen, und den Rest kennen Sie — Lizenzkosten für Mid-Market und Enterprise sind um Zehnerpotenzen gestiegen. Das ist keine LinkedIn-Geschichte, das ist die Realität in Budgets, die gerade die CFO-Freigabe für 2026 durchlaufen.
Wichtig: Diese Änderung wird nicht „vorbeigehen". Verlängerungen dreijähriger Verträge, die vor der Übernahme unterzeichnet wurden, kommen jetzt und 2027 dran. Für einen großen Teil des CZ/SK-Marktes ist das der Entscheidungsmoment.
Drei reale Alternativen, die heute Sinn ergeben
Proxmox VE
Die häufigste erste Idee. Günstig, Open Source, aktive Community. Funktioniert gut für kleinere Umgebungen und Teams, die gewohnt sind, Dinge selbst zu lösen. Die Grenzen zeigen sich, sobald Enterprise-Anforderungen kommen — zertifizierter SLA-Support für mission-critical Workloads, Enterprise-SSO-Integration, eine verlässliche 5-Jahres-Roadmap, Audit-Compliance. Bei einem mittleren Unternehmen mit 200+ VMs und Production-SLAs beginnt es zu knirschen.
Hyper-V / Windows Server
Eine vernünftige Wahl für Windows-lastige Shops, die bereits ein Microsoft Enterprise Agreement haben. Lizenztechnisch oft keine Mehrkosten, deckt funktional die meisten Standardszenarien ab. Das Problem ist der Lock-in in den Microsoft-Stack und ein eingeschränkter Weg zu Cloud-Native-Architektur. Ein Schritt zur Seite, nicht nach vorn.
Red Hat OpenShift Virtualization
Die einzige der drei, die die Infrastruktur nach vorn bringt, nicht zur Seite. Warum: VMs und Container laufen auf einer Plattform (basierend auf KubeVirt), sodass die VMware-Migration kein bloßer Hypervisor-Tausch ist — sondern ein Schritt zu einer einheitlichen Plattform, auf der Sie in 2–3 Jahren auch Cloud-Native-Anwendungen betreiben. Microsoft Ignite 2025 hat zudem die GA von OpenShift Virtualization auf Azure Red Hat OpenShift bestätigt, ein unterstützter Weg in Azure ist also offen.
Warum OpenShift Virtualization + Ansible aus Langzeitarchitektur-Sicht
Das Schlüsselmerkmal, das den Unterschied auf dem Papier und im Betrieb macht: Sie müssen keine zwei parallelen Welten betreiben. Heute betreiben die meisten Firmen eine Plattform für VMs (VMware) und eine zweite für Container (meist OpenShift oder ein anderes Kubernetes). Zwei Betriebsteams, zwei Skill-Sets, zwei Upgrade-Roadmaps, zwei Support-Verträge. OpenShift Virtualization vereint sie — derselbe Cluster, dieselbe API, dasselbe Betriebsmodell.
Red Hat hat am 15. April eine Referenzarchitektur namens Proximity automation veröffentlicht, die beschreibt, wie man den VM-Betrieb über die Ansible Automation Platform aus einem Cloud-Management-Cluster steuert, ohne SSH-Kanäle nach on-prem zu öffnen. Das ist das Pattern, das VMware+vRA heute bietet, im OpenShift-Ökosystem fügt es sich natürlicher und ohne Lizenz-Overhead ein.
Für Enterprises ist das technisch und politisch sauberer — ein Vendor, ein Support, ein Zertifizierungspfad für das Team.
---
# VMware-VM nach OpenShift Virtualization via MTV migrieren (Migration Toolkit
# for Virtualization). Aus AAP gestartet — kein SSH nach on-prem, nur API.
- name: Migrate workload from vSphere to OpenShift Virtualization
hosts: localhost
tasks:
- name: Migrationsplan erstellen (mappt Netzwerk + Storage 1:1)
redhat.openshift_virtualization.migration_plan:
name: "wave-03-billing"
source_provider: "vsphere-prod" # in MTV registriert
target_namespace: "billing-vms"
vms: "{{ batch_vms }}" # 10–20 VMs pro Welle
warm: true # Warm-Migration = minimale Downtime
- name: Migration starten und auf Abschluss warten
redhat.openshift_virtualization.migration:
plan: "wave-03-billing"
state: started
register: result
- name: Sicherstellen, dass alle VMs laufen
ansible.builtin.assert:
that: result.migrated | length == batch_vms | lengthWichtiger Punkt: Warm-Migration hält VMs bis zum finalen Cutover am Laufen — Downtime in Minuten, nicht Stunden. Details in der MTV-Dokumentation.
Bei einer Umgebung mit ~380 VMs haben wir die Migration einer Anwendungswelle von einem geplanten 4-Stunden-Fenster auf einen 12-minütigen Warm-Cutover reduziert. Das gesamte Estate verließ VMware in 9 Monaten, in 14 Wellen. Illustrative Werte — vor Veröffentlichung verifizieren.
Reality Check: Drei Dinge, die Ihnen niemand im ersten Call sagt
- Es ist nicht kostenlos. Die Lizenzgebühr für OpenShift + AAP ist nicht null. Sie verschieben Kosten vom VMware-Vertrag in den Red-Hat-Vertrag. Die Einsparung kommt aus der langfristigen TCO — weniger Betriebsteams, weniger Tools, weniger Integrationen — nicht aus dem Preis im ersten Jahr.
- Das Migrationsprojekt dauert 6–18 Monate. Es hängt von der Estate-Größe, der Dokumentationsqualität und der Lernbereitschaft des Teams ab. Für 500 VMs rechnen Sie mit einem Jahr. Für 2 000+ VMs mit zwei Jahren, aufgeteilt in Wellen.
- Sie brauchen ein Kubernetes-erfahrenes Team oder einen Partner. Ein VMware-Admin, der noch nie ein Terminal für
kubectlgeöffnet hat, lernt OpenShift Virtualization nicht am Wochenende. Es ist ein kultureller Übergang, nicht nur ein technischer.
Realistischer Entscheidungs-Zeitplan
Wenn Ihr Vertrag 2027 ausläuft, planen Sie so:
Monate 1–2 · Proof-of-Concept ↳ Einige nicht produktive Workloads auf einem kleinen OpenShift-Cluster. ↳ Beantwortung der Frage: passt es Ihnen technisch? Monate 3–5 · Pilotmigration ↳ 10–20 produktive VMs in einen dedizierten Cluster. ↳ Validierung des Betriebsmodells, Tuning der Ansible-Playbooks, Training. Monate 6–12 · Migration in Wellen ↳ Kein „Big Bang" — systematische Wellen nach Anwendungs-Clustern. ↳ Parallelbetrieb mit VMware, schrittweiser Ausstieg. Monat 12+ · Konsolidierung und Optimierung ↳ Erst jetzt sehen Sie die echte TCO.
Wer 2027 verlängern muss und bis 2027 mit dem PoC wartet, verpasst das Fenster. Realistisch ist es Zeit anzufangen — heute, nicht „nach Weihnachten".
Häufige Fragen
Müssen wir alles auf einmal migrieren?
Nein. Das empfohlene Modell ist Parallelbetrieb — OpenShift Virtualization läuft neben VMware, Workloads wandern in Wellen nach Anwendungscluster. Ein großer Teil des Estate kann den VMware-Vertrag auslaufen lassen, während kritische Apps schon auf der neuen Plattform laufen.
Was ist mit Apps, die spezifische VMware-Features brauchen (DRS, vMotion)?
OpenShift Virtualization hat Äquivalente — Live-Migration statt vMotion, Descheduler statt DRS. Einige Edge-Cases (z. B. NSX-T-Abhängigkeit) erfordern ein Netzwerk-Redesign, das der PoC aufdeckt. Deshalb ist der PoC der erste, nicht überspringbare Schritt.
Müssen wir das ganze Team auf Kubernetes umschulen?
Nicht das ganze Team. Day-2-VM-Betrieb über Ansible sieht aus wie vorher — Playbooks, nicht kubectl. Tiefere Kubernetes-Kenntnis brauchen 2–3 Personen, der Rest arbeitet über die Automatisierungsschicht. Mehr im IaC-Artikel.
Wie schnell amortisiert sich die Investition?
Der TCO-Break-even liegt typisch bei 18–30 Monaten — abhängig von Estate-Größe und wie viele Tools Sie ablösen. Die Einsparung ist nicht die Lizenz im Jahr 1, sondern die Konsolidierung zweier Plattformen (VMs + Container) in eine. Die reale Zahl gibt es nach dem Pilot.
Fazit
Die VMware-Migration ist keine technische Entscheidung. Sie ist eine strategische Entscheidung darüber, wie Ihre Infrastruktur 2030 aussieht — und ob Sie sie unter Kontrolle haben oder sie nur betreiben.
Steht Ihre VMware-Verlängerung an?
Wir gehen den Scope Ihrer konkreten Umgebung durch — VM-Anzahl, Abhängigkeiten, realistischer Zeitplan und TCO. Kein Sales-Pitch, 20 Minuten mit einem Senior-Architekten.
20-Min-Call buchen →