VMware-Exit in eine Schweizer Cloud: Checkliste

Ohne diese Liste ist jeder Cutover Theater. Sie wird einmal erstellt, dient allen Wellen und bestimmt den Kalender.

• Cluster, Hosts und Anzahl VMs je Cluster
• OS und Version jeder VM, mit bereits abgelaufenen Support-Enden
• Active-Directory-Abhängigkeiten: Controller, DNS, GPOs
• VLANs und Port-Groups, mit den zugehörigen Filterregeln
• Aktuelle Backup-Kette und der tatsächliche Ablageort der Kopien
• RPO und RTO, die das Business erwartet, nicht die aus einem alten Vertrag
• Windows-Server- und SQL-Lizenzen: Lizenzmodell und was übertragbar ist
• Site-to-Site-Verbindungen, VPNs und exponierte öffentliche IP-Adressen
• VMs ohne benannten fachlichen Owner: diese Zeile verzögert Projekte

Legen Sie Ihren Broadcom-Verlängerungstermin in den Kalender und rechnen zurück. Richtwert für 40 bis 120 VMs: T-16 Wochen das Inventar und die Wahl der Wellen; T-12 das Pilot mit 10 bis 20 VMs, Netz, Backup, eine Windows- und eine Linux-App; T-8 der Wellen-Import, beginnend mit allem, das dreissig Minuten Stillstand verträgt; T-4 der Cutover der letzten Workloads, Fenster für Fenster; T-0 vSphere-Abschaltung und Vertragsende. Unter acht Wochen: eine kurze Broadcom-Verlängerung verhandeln statt den Termin halten, drei Monate Lizenz kosten weniger als ein misslungener Cutover am Sonntagabend. Und entscheiden Sie früh, wer ausführt (Abschnitt 9): das verschiebt den Kalender am stärksten.

Das Pilot ist keine Demo: es ist der Entwurf des Runbooks, dem Ihre Wellen folgen. Es muss also jede Schwierigkeit, die Sie hundertmal treffen werden, einmal enthalten, und nichts weiter. Ein Hidora-Ingenieur rahmt es mit Ihnen.

• Zehn bis zwanzig VMs: genug, um Probleme zu zeigen, wenige genug für einen Neuanfang
• Eine Windows- und eine Linux-Anwendung, um beide Lizenzketten zu prüfen
• Eine Last, die dreissig Minuten angekündigten Stillstand verträgt
• Mindestens eine Active-Directory-Abhängigkeit, sonst bleibt die Site-to-Site-Strecke ungetestet
• Ein Volume zum Wiederherstellen, um den Restore und nicht nur das Backup zu prüfen
• Ein fachlicher Owner, der während des Fensters erreichbar ist
• Vom Pilot ausgeschlossen: die kritischste Last und jede VM, deren Topologie niemand kennt

Hikube importiert VMDK, QCOW2 und ISO. Lift-and-Shift behält das OS: keine zwingende Neuentwicklung. Windows Server wird nutzungsbasiert lizenziert. Instanz-Details: die Cloud-Instanzen.

• Zwei VM-Listen: dreissig Minuten Stillstand tolerierbar oder Hot-Replication nötig
• vCPUs je Windows-VM vor dem Pilot gezählt: die Lizenz folgt der Nutzung
• VMware-Gasttools entfernt, Agents der neuen Plattform installiert
• Start nach dem Import geprüft: Netz, gemountete Disks, Anwendungsdienste
• Beginnen Sie nicht mit Kubernetes, ausser die Anwendung ist bereits containerisiert

Prod, DMZ, Backup und Admin auf Hikube-VPC-Subnetze abbilden. Komplexe NSX-Mikrosegmentierung mappt nicht immer 1:1, planen Sie einen Workshop statt einer automatischen Übersetzung. Details: das private VPC-Netz.

• Zuordnungstabelle VLAN → Subnetz, eine Zeile je Netz
• Adressplan vor dem ersten Import festgelegt, nicht währenddessen
• Filterregeln neu geschrieben und geprüft, auch die, zu denen sich niemand bekennt
• VPN oder Site-to-Site-Verbindung zum bestehenden Active Directory aufgebaut und getestet
• DNS-Auflösung in beide Richtungen validiert
• Öffentliche IPs und externe DNS-Einträge erfasst, TTL vor dem Fenster gesenkt

Backup nicht am Cutover-Tag «einschalten». Das Backup im Schweizer Tenant ersetzt die Veeam- oder On-prem-Komponente nach dem Import, und die Kopien bleiben in der Schweiz. Details: das managierte Backup.

• Backup auf den importierten VMs aktiv, bevor sie in Betrieb gehen
• RPO und RTO aus Abschnitt 1 in die Backup-Policy übertragen
• Ein vollständiger Restore im Pilot ausgeführt und gemessen
• Ablageort der Kopien geprüft: sie bleiben in der Schweiz
• Die alte Backup-Kette bis zum Ende der letzten Welle behalten

Eine Welle fasst VMs zusammen, die Fenster und Owner teilen, und beginnt mit dem, was angekündigten Stillstand verträgt. Am Ende jedes Fensters sind die Punkte unten erfüllt oder nicht: fehlt einer, ist es ein Rollback und kein Punkt für Montag.

• Fenster angekündigt, fachlicher Owner und Ingenieur anwesend
• Die VM startet und alle ihre Dienste antworten
• Ein Test-Schreibvorgang der Anwendung ist nach der Umschaltung in der Datenbank sichtbar
• Antwortzeiten im vor der Migration gemessenen Rahmen, nicht «sieht gut aus»
• Backup der migrierten VM erstellt und geprüft
• Das Monitoring erfasst die VM und ihre Alarme sind aktiv
• Kein Nutzerticket zur Umschaltung in den folgenden zwei Stunden

Ein nachträglich dokumentierter Rollback ist keiner. Er existiert nur, wenn die Quelle startfähig bleibt und die Entscheidungszeit vor dem Öffnen des Fensters festgelegt ist, solange noch niemand gebunden ist.

• Quell-VM auf vSphere ausgeschaltet, aber unverändert; während der Welle nie gelöscht
• Entscheidungsfrist vor dem Öffnen des Fensters festgelegt
• Eine benannte Person entscheidet den Rollback: kein Konsens um drei Uhr morgens
• DNS- und IP-Umschaltung reversibel, TTL bereits gesenkt
• Während des Fensters geschriebene Daten: identifiziert, dann nachgespielt oder bewusst verworfen
• vSphere bis zur Validierung der letzten Welle lizenziert halten

Ein Hidora-Ingenieur rahmt Inventar, Netzwerk-Workshop und Pilot: das ist immer der Start, und das Ergebnis ist das Runbook des Pilots. Für die Fabrik drei Aufstellungen. Ihr Team fährt sie mit diesem Runbook, wenn es die Kapazität hat. Oder Hidora übernimmt sie als Projektleistung per SOW, nach Zeitaufwand oder Meilensteinen, zusätzlich zum PAYG. Oder ein Partner-Integrator führt das Projekt und behält die Kundenbeziehung. Ein Team von zwei oder drei Personen trägt keine hundert VMs nebenbei: entscheiden Sie beim Rahmen, nicht am letzten Wochenende.

Zwei Fragen vor der Signatur, nicht danach. Support: 24×7-Überwachung und Pikett der Infrastruktur bei Hidora, Support-Desk an Werktagen 08:00–18:00 CET auf Französisch und Englisch, maximale Reaktionszeiten je Priorität (P1 kritisch, 4 Std.). Ihre OS und Anwendungen bleiben in Ihrer Überwachung, genau wie unter vSphere; die genaue Aufteilung steht auf den Support-Umfang. Reversibilität: der Vertrag regelt die Rückgabe am Ende der Beziehung, Verfahren, Aufbewahrungsfrist und allfällige Gebühren sind dort festgelegt, und der Vertrag ist massgebend (die AGB). Technisch ist nichts proprietär: Volumes sind als Disk-Image exportierbar und der Objektspeicher ist S3-kompatibel. Wenden Sie dieselbe Checkliste auf Ihren nächsten Anbieter an, auch auf uns.