VMware-Exit-Checkliste: In 10 Schritten raus aus der Broadcom-Kostenfalle

Bevor Sie migrieren, brauchen Sie Zahlen: Was kostet der Verbleib bei VMware wirklich – und bis wann müssen Sie entscheiden?

• Laufzeit und Kündigungsfristen der aktuellen VMware-Verträge dokumentieren
• Neues Broadcom-Angebot einholen (Kernbasierte Subscription, Mindestabnahme beachten)
• 3-Jahres-Vergleichsrechnung erstellen: VMware-Verbleib vs. Migration inkl. Projektkosten
• Support-Status prüfen: Wie lange erhält Ihre aktuelle Version noch Updates?

Sie können nur migrieren, was Sie kennen. Erfassen Sie die komplette virtuelle Landschaft.

• Alle VMs inventarisieren: vCPU, RAM, Storage, Betriebssystem, Snapshots
• Hosts und Cluster dokumentieren (CPU-Generation, RAM, Netzwerkkarten)
• Storage-Anbindung erfassen: SAN/NAS/vSAN, Protokolle (iSCSI, NFS, FC)
• vSphere-Features listen, die aktiv genutzt werden (HA, DRS, vMotion, Fault Tolerance)
• Backup-Integration prüfen: Welche Software sichert wie (z. B. Veeam mit vSphere-API)?

Nicht jede VM ist gleich wichtig. Die Priorisierung entscheidet über die Migrationsreihenfolge.

• Jede VM einer Kritikalitätsstufe zuordnen (geschäftskritisch / wichtig / unkritisch)
• Abhängigkeiten kartieren: Welche Systeme kommunizieren miteinander?
• Maximale tolerierbare Ausfallzeiten (RTO) pro System definieren
• Software mit Hypervisor-Bindung identifizieren (Lizenzierung, Agents, Appliances)
• Herstellersupport prüfen: Ist Ihre Fachanwendung auf dem Ziel-Hypervisor supportet?

Es gibt keinen „besten" Hypervisor – nur den passenden für Ihre Umgebung und Ihr Team.

• Proxmox VE: Open Source, keine Lizenzkosten, Linux-Know-how nötig – ideal für kostensensitive Umgebungen
• Microsoft Hyper-V: in Windows Server enthalten, gute Wahl bei Microsoft-lastiger Infrastruktur
• Nutanix AHV: Hyperconverged, stark bei Skalierung und Management-Komfort, höhere Kosten
• Team-Know-how ehrlich bewerten: Wer betreibt die Plattform nach dem Projekt?
• Management-, Monitoring- und Backup-Ökosystem des Kandidaten prüfen

Die meisten Migrationsprobleme entstehen beim Storage – nicht bei den VMs.

• Kompatibilität des bestehenden Storage mit dem Ziel-Hypervisor prüfen
• Entscheiden: Storage weiterverwenden, neu beschaffen oder auf Hyperconverged wechseln
• Backup-Software auf Unterstützung des neuen Hypervisors prüfen (Veeam unterstützt z. B. Proxmox und Hyper-V)
• Replikation und Disaster-Recovery-Konzept an die neue Plattform anpassen

Testen Sie die Zielplattform mit echten Workloads, bevor Sie sich festlegen.

• PoC-Umgebung mit repräsentativer Hardware aufsetzen (2–3 Hosts)
• 2–3 unkritische Produktions-VMs testweise migrieren
• Performance vergleichen: CPU, Storage-I/O, Netzwerk-Latenz
• Administrative Abläufe durchspielen: Backup/Restore, Live-Migration, Updates, Monitoring
• Hochverfügbarkeit testen: Was passiert beim Host-Ausfall wirklich?

Big-Bang-Migrationen scheitern. Planen Sie in Wellen – von unkritisch zu kritisch.

• Migrationswellen definieren: Welle 1 Test/Dev, Welle 2 wichtige Systeme, Welle 3 geschäftskritische Systeme
• Wartungsfenster mit den Fachabteilungen abstimmen
• Migrationsmethode pro VM festlegen (Import-Tools, Backup/Restore, Neuinstallation)
• Parallelbetrieb einplanen: Alte Umgebung bleibt bis zur Abnahme lauffähig
• Verantwortlichkeiten und Eskalationswege pro Welle festlegen

Ein Rollback-Plan, der nie getestet wurde, ist kein Plan – er ist eine Hoffnung.

• Rollback-Kriterien definieren: Wann wird abgebrochen und zurückgeschwenkt?
• Rollback mit einer Test-VM tatsächlich durchspielen
• Frische Backups unmittelbar vor jeder Migrationswelle erstellen und verifizieren
• Maximale Rollback-Dauer messen und gegen das Wartungsfenster prüfen

Jetzt zahlt sich die Vorbereitung aus: Migrieren, testen, abnehmen – Welle für Welle.

• Pro VM: migrieren, VM-Tools/Treiber des neuen Hypervisors installieren
• Funktionstest durch die Fachabteilung nach jeder Welle einholen
• Backup-Jobs auf die neue Plattform umstellen und ersten Restore testen
• Monitoring auf die neue Umgebung aufschalten
• Lessons Learned nach jeder Welle: Fahrplan für die nächste Welle anpassen

Das Projekt ist erst fertig, wenn Ihr Team die neue Plattform sicher betreibt.

• Administratoren auf der neuen Plattform schulen (Betrieb, Troubleshooting, Updates)
• Betriebsdokumentation erstellen: Architektur, Standardabläufe, Notfallprozeduren
• VMware-Umgebung nach Abnahmefrist kontrolliert stilllegen und Lizenzen kündigen
• Alte Hosts neu verwenden, verkaufen oder zertifiziert entsorgen
• Abschlussrechnung: Tatsächliche Einsparung gegenüber der Vergleichsrechnung aus Schritt 1 dokumentieren