Ihr VMware‑Ausstieg wird wehtun, wenn Sie nicht jetzt starten: Der 12‑Monats‑Fahrplan eines CTO

Ihr Hypervisor ist inzwischen ein Risiko auf Vorstandsebene. Nach Broadcoms Lizenz‑Umbau stellten viele Unternehmen fest, dass ihre vSphere‑Rechnung nicht nur steigt — sie hat sich verdoppelt, teils schlimmer. Und das ist nicht hypothetisch: Ein US‑Carrier hat Berichten zufolge begonnen, zehntausende VMs von VMware abzuziehen — parallel zu einem Rechtsstreit. Wenn selbst sie den Lock‑in nicht schlucken, warum sollten Sie es können?

Das lösen Sie nicht mit einer Pressemitteilung oder einem zweiwöchigen „Lift‑and‑Shift“. Hypervisor‑übergreifende Live‑Migration gibt es nicht. Ihre NSX‑Konstrukte lassen sich außerhalb von VMware nicht 1:1 abbilden. Und der bequeme Weg — „packen wir alles in EC2“ — führt zu einer neuen Rechnung, die 2–3× Ihrer vollständig amortisierten On‑Prem‑Kosten liegt, sobald Sie Egress, Reserved Instances, Backups und die unvermeidliche Performance‑Überprovisionierung einrechnen.

Die unbequeme Wahrheit: Sie brauchen einen disziplinierten Exit‑Plan — und der beginnt dieses Quartal. Unten finden Sie einen 12‑Monats‑Fahrplan, Technologieoptionen mit realen Abwägungen und die Fallen, in die Teams tappen, wenn sie panisch zur Tür rennen.

Der Entscheidungsrahmen: Vier tragfähige Wege weg von VMware

Wählen Sie eine Spur basierend auf Workload‑Mix, Skills, Latenzanforderungen und Compliance. Das ist ein Portfolio‑Thema, kein Schönheitswettbewerb.

1) KVM‑first HCI (Proxmox VE, Harvester, oVirt‑Derivate)

Ideal für: Linux‑lastige Umgebungen, mittlere Größe (Dutzende bis niedrige Hunderte von Nodes), Teams mit sicherer Linux‑Betriebserfahrung.

• Warum es funktioniert: KVM ist der De‑facto‑Hypervisor unter AWS, GCP und vielen Clouds. Proxmox VE liefert ein aufgeräumtes UI/API, Clustering, Live‑Migration und native Backups. Harvester (KubeVirt + Longhorn) ergänzt bei Bedarf ein Kubernetes‑Substrat, um VM‑ und Container‑Betrieb zu harmonisieren.
• Wirtschaftlichkeit: Proxmox VE ist frei nutzbar; Enterprise‑Repo‑Subscriptions kosten grob €110–€935 pro CPU‑Sockel und Jahr je nach Supportstufe. Selbst mit Support landen Sie meist bei 10–30% Ihrer bisherigen VMware‑Softwareausgaben für vergleichbare Kapazität.
• Abwägungen: Sie verlieren etwas NSX/vSAN‑Ergonomie. Netzwerk‑Overlays (OVN/OVS) und Storage (Ceph/ZFS/Longhorn) bauen Sie selbst oder mit Partnern neu auf.

2) OpenStack (mit KVM, OVN, Ceph)

Ideal für: Private Clouds mit mehreren Teams, Multi‑Tenant‑Bedarf, hohe Betriebsreife.

• Warum es funktioniert: OpenStack bietet IaaS‑Grundfunktionen (Compute, Netzwerk, Storage) mit Quotas, Projekten und soliden APIs. Es ist das, was einer privaten EC2 am nächsten kommt.
• Wirtschaftlichkeit: Die Software ist Open Source; die Kosten liegen im Betrieb. Rechnen Sie mit 24/7‑SRE‑Abdeckung und CI/CD für die Cloud selbst.
• Abwägungen: Komplexität. Wenn Ihr Team noch nie eine Control Plane betrieben hat, lernen Sie das nicht mitten im Produktions‑Exit.

3) Kommerzielle HCI‑Alternativen (Nutanix AHV)

Ideal für: Gemischte Windows/Linux‑Landschaften, Teams, die VMware‑ähnlichen Feinschliff ohne VMware wollen.

• Warum es funktioniert: Reife Management‑Ebene, Windows‑Guest‑Tooling, integriertes Storage‑Networking. AHV ist KVM unter der Haube mit der Control Plane von Nutanix.
• Wirtschaftlichkeit: Kostet echtes Geld, aber für viele Organisationen liegt der TCO dennoch unter dem „neuen VMware“, wenn Sie Broadcom‑Bundles einpreisen, die Sie nicht brauchen.
• Abwägungen: Eine weitere Herstellerbeziehung mit eigenem Roadmap‑Risiko. Weniger DIY‑Flexibilität als Proxmox/OpenStack.

4) Rehost in die Public Cloud (EC2/Azure/GCP)

Ideal für: Kleine Umgebungen oder Teams mit bereits >70% Cloud, bei denen On‑Prem technischer Schuldenstand ist.

• Warum es funktioniert: Schnellster Weg, um einer VMware‑Verlängerung zu entkommen. Reiches Ökosystem für DR, Backups und Managed Services.
• Wirtschaftlichkeit: Sticker‑Schock ist üblich. Im Dauerbetrieb erwarten Sie 1,5–3,0× gegenüber einem gut betriebenen On‑Prem‑Cluster mit gleichem Performance‑Profil — je nach Egress und Disziplin bei Reserved Instances.
• Abwägungen: Latenz, Datenresidenz und Kostenkontrolle. Verschieben Sie keine geschwätzigen, storage‑intensiven, margenschwachen Workloads über diesen Pfad — es sei denn, Sie mögen Überraschungsrechnungen.

Ihr 12‑Monats‑VMware‑Exit‑Plan

0–30 Tage: Freeze, Inventar, Baseline

• Feature‑Freeze: Keine neuen NSX/vSAN‑spezifischen Konstrukte einführen. Keine neuen SRM‑Abhängigkeiten.
• Inventarisieren wie eine Bank: Export mit RVTools oder Ihrem CMDB, aber durch Stichproben am Gast‑OS validieren. Jede VM taggen mit Owner, RTO/RPO, CPU/RAM/IOPS, OS und Abhängigkeiten (DNS/AD/NTP, Datenbanken, Message‑Busse).
• Kosten‑Baseline: Die letzten 12 Monate VMware‑Positionen, Supporttickets, Backup‑Lizenzen, Strom und Fläche. Sie brauchen das, um den Business Case zu untermauern.
• Pet Projects beerdigen: Kann binnen 48 Stunden niemand einen Owner für eine VM benennen, ab auf den Ausmusterungs‑Pfad. Ballast killt Migrationen.

30–90 Tage: Ziel wählen, Pilot bauen

• Legen Sie sich fest. Überwiegend Linux und In‑House‑Ops? Proxmox VE mit Ceph ist der schnellste praktikable Weg. Brauchen Sie Multi‑Tenant‑Projekte und Quotas, evaluieren Sie OpenStack. Zählen Windows‑Admin‑Komfort und White‑Glove‑UX, shortlistet Nutanix AHV. Ist Ihr Bestand klein oder bereits zu 80% in der Cloud, planen Sie ein Rehost.
• Pilot aufsetzen: Mindestens 3 Nodes (NVMe‑Cache, 25/50Gbps NICs, 256–512GB RAM). Für Proxmox zusätzlich Proxmox Backup Server. Beim Storage je nach Größe mit Ceph oder ZFS‑Spiegeln starten.
• Konvertierungen durchspielen: virt‑v2v für Linux‑VMs und Windows verwenden (VMware Tools entfernen, virtio‑Treiber installieren). Rechnen Sie mit einem Wartungsfenster; hypervisorübergreifende Live‑Migration gibt es nicht.
• Die Basics beweisen: Backups, Restores, Snapshots, Template‑Builds und RBAC. Wenn Sie keinen Windows‑DC aus dem neuen Stack wiederhergestellt haben, haben Sie nichts getestet.

90–180 Tage: Netzwerk, Storage und Welle 1

• Netzwerkplan: VLANs und Overlays mit OVN/OVS oder Ihrer Switch‑Fabric nachbauen. NSX‑Firewall‑Regeln auf Host‑Firewalls oder Upstream‑Firewalls abbilden. DHCP/DNS hochverfügbar auslegen.
• Storage‑Plan: vSAN ≠ Ceph. Starten Sie mit 3–5 MON/MDS‑Hosts mit SSD/NVMe. IOPS unter realen Workloads validieren. TRIM/UNMAP in den Gästen aktivieren, um I/O‑Blähung zu vermeiden.
• Automatisierung: Jetzt konsequent IaC einführen. OpenTofu/Terraform‑Provider für Proxmox oder Ihre Zielplattform nutzen. Golden Images mit Packer/Cloud‑Init bauen.
• Welle 1 der Migrationen: Drei Klassen wählen: eine zustandslose App, eine mittlere Datenbank und einen Windows‑Dienst (Druck/ADCS/Legacy‑Line‑of‑Business). Performance und Betriebsfähigkeit validieren. Dokumentieren Sie die Runbooks, die Sie tatsächlich genutzt haben — nicht die, die Sie geschrieben haben.

180–270 Tage: Skalierung, DR und Governance

• Skalieren: Auf Zielkapazität ausbauen. Zweites Rack oder Cluster für DR hinzufügen. Backups Offsite replizieren. Bei Proxmox Quorum‑Ausfälle und Fencing testen.
• DR‑Muster: Akzeptieren Sie die Realität: Für die meisten VMs ist das Failover cold‑to‑warm. Boot‑Reihenfolge, DNS‑Umschaltungen und Datenbank‑Promotion skripten. Den gesamten Ablauf stoppen; sagt Ihr RTO 60 Minuten und Sie landen bei 140, passen Sie Plan oder SLA an.
• Observability: Prometheus + Grafana für Hosts und Gäste; Proxmox‑ oder OpenStack‑Exporter; Log‑Aggregation mit Loki/ELK. Noisy Neighbors identifizieren und mit Ressourcengrenzen oder dedizierten Nodes hinterlegen.
• Zugriff und Audit: SSO für Konsolen und APIs, kurzlebige Tokens, MFA‑Pflicht. Wenn Dienstleister beteiligt sind (Nearshore oder anderswo), an Geräte‑Posture und IP‑Allowlists binden.

270–360 Tage: Cutover‑Wellen und Außerbetriebnahme

• Wellenplan: Behandeln Sie das wie einen Produkt‑Launch‑Kalender. Freeze‑Fenster 30 Tage im Voraus kommunizieren; komplexe Umzüge im Staging‑Cluster als Trockenlauf üben.
• Performance‑Tuning: CPUs für latenzkritische DBs pinnen, hugepages dort aktivieren, wo es hilft, virtio‑scsi statt Legacy‑Disk‑Typen wählen und NUMA‑Ausrichtung auf großen Hosts verifizieren.
• Security‑Hardening: UEFI Secure Boot auf Hosts, verschlüsselte Boot‑Drives, TPM‑Passthrough wo nötig, Patch‑Pipelines für Hosts. Bei AMD EPYC SEV‑ES für VM‑Speicher‑Verschlüsselung in feindlichen Multi‑Tenant‑Clustern evaluieren.
• VMware verkleinern: Ausgemusterte Hosts abschalten. Konfigurationen archivieren. Eine kleine Insel nur behalten, wenn es sein muss (z. B. herstellergebundene Appliances). Gehen Sie mit Nutzungsfakten, nicht mit Gefühlen, in die Verlängerungsgespräche.

Was das tatsächlich kostet

Zahlen, die Sie mit in die Finanzabteilung nehmen können. Das sind Richtwerte; tragen Sie Ihre echten Angebote und Strompreise ein.

• Hardware: Ein moderner 1U‑Dual‑Socket‑Server mit 256–512GB RAM, 2×25Gbps NICs und einem Paar 1,6–3,2TB NVMe‑Drives liegt je nach Hersteller und Rabatten bei US$6k–$12k. Für einen bescheidenen vSphere‑Bestand starten Sie typischerweise mit 6–12 Nodes.
• Strom: Ein Virtualisierungs‑Node liegt im Idle bei ca. 150–250W und erreicht 300–500W unter Last. Zehn Nodes mit Ø 300W = ≈3kW. Bei $0,12/kWh sind das ~$315/Monat für 3kW Strom — vor Kühlung und PUE‑Overhead.
• Software/Support: Proxmox VE‑Subscriptions pro CPU‑Sockel liegen grob bei €110 (Basic) bis €935 (Premium) pro Jahr; viele Teams wählen Standard (~€280/Sockel) für Enterprise‑Repo + Support. Ceph ist Open Source; erwägen Sie bezahlten Support nur, wenn In‑House‑Skills fehlen. AHV und OpenStack‑Distributionen variieren; Sie zahlen für Support und Bequemlichkeit.
• Personal: Das ist der wahre Kostenblock. Rechnen Sie mit 1–2 FTE fokussiert über 6–12 Monate, um einen Bestand von 150–300 VMs zu planen, zu pilotieren und zu migrieren — plus Unterstützung der App‑Owner fürs Testen. Wenn Sie diese Kapazität nicht haben, kann ein dedizierter Nearshore‑SRE‑Pod mit 6–8 Stunden Überschneidung den Kalender komprimieren, ohne die Produkt‑Roadmap zu zerlegen.

Fallstricke, die Zeitpläne sprengen

• Der Versuch, hypervisorübergreifend live zu migrieren. Geht nicht. Planen Sie Cutover‑Fenster mit Delta‑Syncs, nicht mit Magie. rsync/ZFS send einsetzen, um Daten vorzubereiten, wo es sinnvoll ist.
• Windows‑Aufwand unterschätzen. VMware Tools sauber entfernen, virtio‑Treiber vorab installieren und Aktivierung/Lizenzierung validieren. Probleme mit Zeitsynchronisation und Domänenvertrauen erwischen Sie um 2 Uhr morgens.
• NSX‑Übertragungen ignorieren. Verteilte Firewall‑Regeln und Mikrosegmente migrieren nicht von allein. Entweder upstream (Palo Alto, Fortinet, etc.) neu aufbauen oder hostbasierte Regeln implementieren und etwas Sprawl akzeptieren.
• vSAN‑Performance 1:1 voraussetzen. Ceph und Longhorn verhalten sich bei zufälligen Schreiblasten anders. fio unter Ihren realen Mustern laufen lassen, nicht mit Marketing‑Defaults.
• Backup/Restore‑Proben überspringen. Ein Backup, das Sie nie zurückgespielt haben, ist eine Geschichte, keine Kontrolle. Beweisen Sie Voll‑VM‑ und File‑Level‑Restores aus Ihrem neuen Stack vor jedem Produktiv‑Cut.
• Owner außen vor lassen. Erfahren App‑Owner von der Migration per Status‑Mail, scheitern Sie im UAT und rollen zurück. Holen Sie sie früh in die War Rooms.

Was ist mit Kubernetes?

Kubernetes ist kein Hypervisor. Wenn Sie bereits container‑lastig sind, nutzen Sie den Moment, um einen Teil der VM‑Wildwuchs zu beseitigen — aber machen Sie Ihren VMware‑Exit nicht zur Plattform‑Neuentwicklung. Zwei vernünftige Muster:

• KubeVirt oder Harvester für den VM‑Subset, der nahe bei Ihren Clustern leben muss. Funktioniert gut für Linux‑Services und bestimmte stateful Apps. Kein guter Ort für alte Windows‑Line‑of‑Business‑Anwendungen.
• Bewusstes Split‑Brain: Proxmox/OpenStack für VMs, Kubernetes für Container. Identität und Observability föderieren. Zwingen Sie nicht alles durch eine API, nur weil es elegant ist.

Security und Compliance: Bauen Sie die Risiken von gestern nicht nach

• Kurzlebige Anmeldedaten: OIDC/SAML in Ihre Virtualisierungs‑API/Konsole mit erzwungener MFA und Session‑TTLs. Beenden Sie die Kultur langlebiger Admin‑Passwörter.
• Secrets und Images: Attestierung der Image‑Pipeline. VM‑Templates signieren. Secrets in einem zentralen Vault mit projektweiser Vergabe speichern.
• Datenresidenz und Datenschutz: Wenn Sie in oder für US‑Bundesstaaten mit verschärften Datenregeln operieren, halten Sie Telemetrie und Backups regionsgebunden. Behandeln Sie Metadaten (insb. Geolocation‑ und IP‑Daten) als reguliert — die Schlagzeilen bewegen sich dorthin.
• Host‑Härtung: UEFI Secure Boot, TPM, FDE auf Host‑OS‑Disks und ein schneller Takt für Microcode/Kernel‑Updates. Warten Sie nicht auf einen CVE‑Sturm, um Rolling Reboots zu üben.

Wann ein Nearshore‑Pod wirklich hilft

Es geht nicht darum, Leute auf eine Migration zu werfen. Es geht darum, Ihre Kerningenieure auf das Produkt fokussiert zu halten, während ein spezialisiertes Team die undifferenzierte Schwerstarbeit übernimmt: Inventar‑Plausibilisierung, Host‑Builds, Netzwerk/Storage‑Inbetriebnahme, Konvertierungs‑Runbooks und Cutovers außerhalb der Geschäftszeiten. In Brazil bekommen Sie 6–8 Stunden Überschneidung mit US‑Zeitzonen und Senior‑Linux‑Talent, das 20–30% günstiger ist als US‑Onshore — ohne die 10–12‑stündigen Lücken von Offshore. Nutzen Sie diese Überschneidung für das Knifflige: Treiberprobleme auf Windows Server 2012 R2, Ceph‑Placement‑Group‑Tuning oder OVN‑ACLs, die sich nicht wie NSX verhalten.

Realitätscheck der Zeitpläne

Wir haben 150–300 VM‑Bestände in 6–9 Monaten bewegt — mit einem dedizierten Team und starker Einbindung der App‑Owner. Über 1.000 VMs hinweg planen Sie 9–18 Monate in Wellen. Erwartet Ihr Leadership „Ende des Quartals“, weil ein Cloud‑Anbieter Credits gewunken hat, kontern Sie mit einem Migrationskalender, der an App‑Kritikalität und Saisonalität des Geschäfts hängt. Der Preis für Hast wird meist in nächtlichen Rollbacks und Reputationsschäden bezahlt, nicht in Heldentaten.

Warum Sie jetzt starten sollten

Zwei Gründe. Erstens: Ihre Verlängerungsuhr tickt. Jeder Monat Verzögerung verengt Ihre Optionen und spielt dem Platzhirsch Verhandlungsmacht zu. Zweitens: Der Markt bewegt sich. Dass T‑Mobile öffentlich über einen massiven VMware‑Exit spricht, ist ein Signal, keine Anomalie. Hardware‑Lieferzeiten sind 2026 weiterhin holprig. Sie wollen Ihre POs platzieren, bevor alle beim gleichen Plan B aufwachen.

Kernpunkte

• Spur wählen je nach Workload‑Mix und Ops‑Reife: KVM‑HCI (Proxmox/Harvester), OpenStack, Nutanix AHV oder gezieltes Cloud‑Rehost.
• Hypervisorübergreifende Live‑Migration gibt es nicht. Planen Sie Cutover‑Fenster mit vorab bereitgestellten Daten und getesteten Runbooks.
• Mehr für Menschen als für Software budgetieren. Rechnen Sie mit 1–2 fokussierten FTE über 6–12 Monate für 150–300 VMs.
• Netzwerk und Storage bewusst neu aufbauen: OVN/OVS für Overlays, Ceph/ZFS/Longhorn für Storage. NSX/vSAN‑Verhalten nicht voraussetzen.
• Restores vor jedem Produktiv‑Cutover testen. Ein Backup, das Sie nie zurückgespielt haben, ist ein Gerücht.
• Den Exit für Security‑Modernisierung nutzen: SSO/MFA zu Konsolen, signierte Images, verschlüsselte Hosts und kurzlebiger Zugriff.
• Nearshore‑Pods mit 6–8 Stunden Überschneidung können Zeitpläne komprimieren, ohne die Produkt‑Roadmap zu entgleisen.
• Jetzt starten, um Verhandlungsspielraum zu behalten und Hardware/Anbieter‑Engpässe zu vermeiden, wenn alle zum Ausgang drängen.