Landing-Zone-Kompatibilität
Netzwerksegmentierung, IAM-Modell und Security Controls vor der Migration verifizieren.
Verschachteltes VMware-ESXi-Lab auf STACKIT erstellen
STACKIT
Überblick: Relocate
Abschnitt betitelt „Überblick: Relocate“Relocate verschiebt Workloads mit minimalen Architektur-Änderungen in ein STACKIT-kompatibles Zielsetup. Im Fokus steht eine schnelle und risikoarme Überführung, nicht die sofortige cloud-native Modernisierung.
Konkret bedeutet Relocate: Das bestehende VM-Betriebsmuster bleibt weitgehend erhalten. Geändert wird vor allem der Zielstandort inklusive Plattformkontrollen, nicht das Laufzeitmodell der Workloads.
Relocate vs. Rehost in STACKIT
Abschnitt betitelt „Relocate vs. Rehost in STACKIT“Relocate und Rehost sind beide Low-Change-Pfade, unterscheiden sich aber in Tiefe und Zielbild der Migration.
- Relocate in STACKIT: Fokus auf Überführung bestehender VM-zentrierter Landschaften in ein kompatibles STACKIT Zielsetup mit möglichst wenig Umformung.
- Rehost in STACKIT: Fokus auf anwendungsbezogenen Lift-and-Shift mit klarer Zielabbildung, Cutover-Design und standardisierten Runbooks für den Factory-Betrieb.
- Betriebliche Konsequenz: Relocate ist oft der schnellste Weg für Estate-Movement, Rehost ist oft der klarere Weg für wiederholbare Wellenumsetzung je Anwendung.
- Planerische Konsequenz: Relocate bei Priorität auf Erhalt bestehender Betriebsmuster, Rehost bei Priorität auf standardisierte Migration über viele Anwendungen.
Vorgehensvarianten bei Relocate
Abschnitt betitelt „Vorgehensvarianten bei Relocate“Relocate kann in zwei operativen Varianten umgesetzt werden, je nach Estate-Grösse, Unterschiedlichkeit und Cutover-Risiko.
- Tool-gestütztes Relocate: Bevorzugt in Large-Scale-Programmen, wenn Durchsatz, Konsistenz und ein wiederholbarer Ablauf der Wellen im Fokus stehen.
- Kontrolliertes manuelles Relocate: Sinnvoll für kleinere oder besondere Workloads, die eine engere manuelle Steuerung brauchen.
- Gemeinsame Qualitätsanforderungen: Beide Varianten brauchen dieselben Cutover-Kontrollen, Rollback-Logik und Day-1-Betriebsreife.
Wann Relocate sinnvoll ist
Abschnitt betitelt „Wann Relocate sinnvoll ist“- Zeitkritische Transition: Strikte Exit-Termine oder Vorgaben zur Datenlokation.
- Geringe Veränderungstoleranz: Fachbereiche können aktuell keine größeren Umbauten tragen.
- Stabile Bestands-Workloads: VM-basierte Muster sind bekannt und betrieblich beherrscht.
- Spätere Modernisierung geplant: Replatform/Refactor ist als Folgeschritt vorgesehen.
Design-Aspekte im STACKIT-Kontext
Abschnitt betitelt „Design-Aspekte im STACKIT-Kontext“Sizing und Performance
VM-Sizing und Storage-Profile neu baseline, um Überprovisionierung zu vermeiden.
Betriebliche Kontrollen
Monitoring-, Backup- und Recovery-Kontrollen ab Tag 1 im Ziel sicherstellen.
Umgang mit grossen Datenmengen
Für sehr grosse VM-Datenbestände Pre-Seeding, Delta-Sync-Fenster und Bandbreitensteuerung vorab festlegen, um Cutover-Downtime zu begrenzen.
Pfad für spätere Modernisierung
Klare Trigger für spätere Replatform/Refactor-Entscheidungen dokumentieren.
Datenmigration bei Relocate
Abschnitt betitelt „Datenmigration bei Relocate“Bei Relocate ist die Datenmigration oft implizit gelöst, weil die gesamte VM inklusive Storage verschoben wird. Trotzdem sollten bei großen Datenmengen explizite Design-Entscheidungen getroffen werden:
- Anbindung im Netzwerk: End-to-End-Durchsatz, Latenz und Stabilität des Pfads für den Transfer im Fenster der Migration verifizieren.
- Storage-Klasse: Quell- und Ziel-Storage-Klassen vor dem Cutover auf erforderliche IOPS-/Throughput-Profile abstimmen.
- Pre-Seeding: Daten möglichst vor dem Cutover übertragen.
- Delta-Synchronisation: Im finalen Fenster nur die letzten Änderungen nachziehen.
- Integritätsprüfung: Prüfsummen und Stichproben-Reads für migrierte Volumes definieren.
- Rollback-Checkpoints: Quell-Snapshots bis zur Abnahme im Ziel vorhalten.
Empfohlener Design-Ablauf
Abschnitt betitelt „Empfohlener Design-Ablauf“- Workload-Abhängigkeiten und betriebliche Rahmenbedingungen bestätigen.
- Zielabbildung in STACKIT inklusive Netzwerk- und Security-Vorgaben definieren.
- Migrationssequenz, Downtime-Annahmen und Rollback-Modell entwerfen.
- Betriebsbereitschaft (Monitoring, Backup, Incident-Prozess) validieren.
- Optimierungs-Backlog für die Zeit nach der Überführung festlegen.
Erforderliche Ergebnisse
Abschnitt betitelt „Erforderliche Ergebnisse“Gemeinsame Ergebnisse für alle Migrationspfade
Abschnitt betitelt „Gemeinsame Ergebnisse für alle Migrationspfade“- Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
- Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
- Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
- Übergabepaket für Migration Factory Setup und Wellenplanung.
Relocate-spezifische Ergebnisse
Abschnitt betitelt „Relocate-spezifische Ergebnisse“- Relocate-Entscheidungsnachweis mit Trade-offs und Exit-Kriterien.
- Zielabbildung pro Workload.
- Cutover- und Rollback-Design.
- Day-1-Betriebscheckliste.
- Post-Relocate-Optimierungs-Backlog.
Diagramm-Schrittreferenz
Abschnitt betitelt „Diagramm-Schrittreferenz“Define Landing Zone
Abschnitt betitelt „Define Landing Zone“Landing-Zone-Vorgaben für die Relocate-Welle als Startpunkt der Ausführung festlegen. Account-Struktur, Netzwerksegmentierung und Basis-Kontrollen so abstimmen, dass bestehende VM-Betriebsmuster ohne Governance-Verstöße übertragen werden können.
Use migration tools
Abschnitt betitelt „Use migration tools“Tool-gestützten Vorgehenspfad für skalierbare, wiederholbare Relocate-Wellen festlegen. Ausführungsrollen, Batches und Rollback-Checkpoints früh festlegen, damit große VM-Landschaften konsistent über mehrere Wellen hinweg übertragen werden.
Asset-Titel
Framework
Asset-Typ
Migration
Anleitung
Migration
Anleitung
Migration
Anleitung
Migration
Blueprint
Migration
Runbook
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Runbook
Install
Abschnitt betitelt „Install“Manuelle Installationsschritte für nicht tool-gestützte Ausnahme-Workloads beschreiben.
-
Ziel-VM und Storage vorbereiten: Ziel-VM erstellen, erforderliche Disks anbinden und CPU-/Memory-Sizing anhand gemessener Werte aus der Quelle ausrichten.
-
Erforderliche Basis-Komponenten installieren: Hypervisor-Guest-Tools, OS-Pakete und Runtime-Voraussetzungen einrichten, damit der Workload stabil starten kann.
-
Workload-Artefakte übertragen: Disk-Images, Boot-Dateien und Service-Units/Skripte über einen kontrollierten Transfer-Pfad kopieren.
-
Boot- und Host-Baseline prüfen: Erfolgreichen Boot, Dateisystem-Mount-Integrität und Kernnetzwerk-Erreichbarkeit vor der Konfiguration verifizieren.
- Runbook Blueprint
- Cloud-Design-Patterns
Manuelle Konfiguration und den Abgleich der Parameter im Ziel festlegen.
-
System- und Parameter der Anwendung angleichen: Hostname, DNS, Synchronisierung der Zeit und Umgebungswerte gemäß Workload-Anforderungen setzen.
-
Security- und Zugriffsmodell konfigurieren: Regeln für Zugriffe, Service-Credentials und administrative Grenzen für den Betrieb im Ziel anwenden.
-
Betriebs-Basis aktivieren: Monitoring-Agenten, Log-Forwarding, Backup-Jobs und Restore-Test-Hooks einrichten.
-
Konfigurationsparität prüfen: Wichtige Runtime-Parameter mit der Basis der Quelle vergleichen und akzeptierte Abweichungen dokumentieren.
- Runbook Blueprint
- Migrationsplan
Manuelle Deployment-Reihenfolge und Handover-Checks definieren.
-
Cutover-Sequenz ausführen: Schreibzugriffe auf die Quelle stoppen, finalen Delta-Sync fahren und den Ziel-Workload in der freigegebenen Reihenfolge aktivieren.
-
Verhalten des Service validieren: Smoke- und Critical-Path-Tests inklusive Konnektivität zu abhängigen Systemen durchführen.
-
Stabilisieren und überwachen: Schlüsselmetriken, Fehlerraten und Betriebs-Alarme während des vereinbarten Hypercare-Fensters beobachten.
-
Ownership-Übergang abschließen: Support-Verantwortung, Eskalationswege und Rollback-Abschlusskriterien verbindlich bestätigen.
- Migrationsplan
- Runbook Blueprint
Validation handover
Abschnitt betitelt „Validation handover“Festlegen, wie Relocate-Ergebnisse in das gemeinsame Validation-Gate einfliessen. Technische Evidenz, aktualisierte Risiko-Logs und operativen Abnahme-Status bündeln, damit die Wellen-Governance Entscheidungen ohne Rework treffen kann.