Projekt anfragen
Gang zwischen Serverschränken in einem Rechenzentrum mit einem Wartungswagen samt Monitor

Migration · Wellenplan, Cutover, Rollback

Cloud-Migration planen und sicher umsetzen

Vom einzelnen Server bis zur ganzen Anwendungslandschaft: SKAFFON plant und führt den Umzug auf STACKIT, AWS, Azure oder Google Cloud durch, mit einem geprüften Rückweg für jede Welle.

Migration anfragen Zur 6R-Entscheidungstabelle
  • Inventar mit Abhängigkeitskarte
  • Landing Zone als Infrastructure as Code
  • Cutover-Drehbuch mit Rückfallpunkt

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Wenn Vertragsende, Hardware oder Anbieterwechsel den Takt vorgeben

Migrationen beginnen selten aus Neugier: ein auslaufender Rechenzentrumsvertrag, Hardware am Ende der Lebensdauer, geänderte Lizenzbedingungen, Anforderungen an Datenstandort oder Betreiberkontrolle, oder der Wechsel von einem Cloud-Anbieter zu einem anderen. Jeder Auslöser setzt andere Prioritäten: Bei einem festen Vertragsende zählt der Termin, bei einem Anbieterwechsel die Datenübernahme.

Wir gliedern jedes Vorhaben in Phasen; für jeden Schritt ist ein Rückweg definiert. Welche Plattform das Ziel ist, klären Sie vorher oder gemeinsam mit uns in der Cloud-Beratung.

02Vorgehen

Acht Phasen vom Inventar bis zum übernommenen Betrieb

  1. 01

    Bestandsaufnahme und Inventar

    Ergebnis: Abhängigkeitskarte

    Systeme, Abhängigkeiten (Netzwerkflüsse, Datenbanken, Schnittstellen, Batch-Jobs), Betriebssystem- und Softwarestände, Datenvolumen und Änderungsrate, Verfügbarkeitsanforderungen. Werkzeuge helfen beim Sammeln; die Bewertung bleibt eine fachliche Entscheidung und kein Automatismus.

  2. 02

    Quell- und Zielarchitektur

    Ergebnis: Zielbild

    Heutige und künftige Umgebung im Vergleich: Netzwerk, Identität, Sicherheitszonen, Speicher, Backup, Monitoring. Die Landing Zone des Ziels entsteht als Infrastructure as Code mit OpenTofu oder Terraform; wiederkehrende Serverkonfiguration automatisieren wir mit Ansible.

  3. 03

    Risiken und Abhängigkeiten

    Ergebnis: Risikoliste

    Eine Risikoliste mit benannten Verantwortlichen: gebundene Lizenzen, Latenzempfindlichkeit zwischen Anwendung und Datenbank, nicht dokumentierte Schnittstellen, Datenvolumen im Verhältnis zur verfügbaren Bandbreite.

  4. 04

    Pilot mit einer unkritischen Anwendung

    Ergebnis: erprobte Werkzeugkette

    Eine ausgewählte, nicht geschäftskritische Anwendung wandert zuerst. Der Pilot prüft Werkzeugkette, Netzanbindung, Zugriffsmodell und Betriebsübergabe; die Ergebnisse fließen in den Wellenplan zurück.

  5. 05

    Migrationswellen

    Ergebnis: Systeme im Ziel

    Die übrigen Systeme wandern in Gruppen, geordnet nach Abhängigkeiten und Kritikalität. Datenbanken und Daten folgen einem eigenen Vorgehen, siehe Datenbankmigration.

  6. 06

    Cutover und Rollback

    Ergebnis: Drehbuch je Welle

    Pro Welle ein Drehbuch: Vorbedingungen, Reihenfolge, Verantwortliche, der Entscheidungszeitpunkt „weiter oder zurück“ und der geprüfte Rückweg.

  7. 07

    Abnahmetests

    Ergebnis: Abnahme nach Kriterien

    Funktion, Leistung, Integrationen, Berechtigungen, Backup und Wiederherstellung, Monitoring, gemessen an Kriterien, die vorab mit Ihnen festgelegt wurden.

  8. 08

    Übergabe und Betrieb

    Ergebnis: Runbooks, Einweisung

    Runbooks, Dokumentation, Einweisung. Den Betrieb übernimmt Ihr Team, oder SKAFFON als Cloud-Betrieb.

03Strategie

Rehost, Replatform, Retire: wie wir Ihre Workloads einordnen

Die „6 R“ sind ein gängiges Raster für Migrationsstrategien: Rehost, Replatform, Repurchase, Refactor, Retire, Retain. Die Tabelle zeigt unseren Startpunkt je Workload-Typ für die Diskussion im Assessment; Lizenz, Datenmenge und Teamkompetenz verschieben das Ergebnis.

Üblicher Startpunkt der Migrationsstrategie je Workload-Typ
Workload-TypÜblicher StartpunktBegründung und Prüfpunkte
Standard-Server mit fester Konfiguration (Fileserver, interne Tools)Rehost (Lift-and-Shift)Geringster Änderungsaufwand. Prüfen: Lizenzbindung, Treiber, Abhängigkeit von Hardware.
Web- oder Anwendungsserver mit eigener DatenbankReplatformDatenbank auf verwalteten Dienst oder Cluster heben, Anwendung nahezu unverändert. Prüfen: Latenz zwischen Anwendung und Datenbank.
Zustandslose, containerfähige DiensteReplatform auf KubernetesBetrieb vereinheitlichen. Prüfen: Konfiguration, Health-Checks, Bedarf an Kubernetes überhaupt; siehe Kubernetes-Beratung.
Monolith mit hohem ÄnderungsdruckRefactor (schrittweise)Nur lohnend, wenn die Weiterentwicklung ohnehin ansteht. Kein Teil einer Termin-Migration.
Standardsoftware mit SaaS-AlternativeRepurchaseDatenübernahme und Funktionsvergleich klären; Vertragsfragen früh anstoßen.
Betrieb ohne Nutzer, Dubletten, AltsystemeRetireAußerbetriebnahme statt Migration, mit Archivierungsentscheidung für Daten.
Systeme mit harter Bindung (Spezialhardware, Zertifizierung, Latenz zur Fertigung)RetainBleibt vorerst; Anbindung an die Zielumgebung planen.
Datenbanken mit hohem VolumenEigene StrategieReplikation und Cutover mit Synchronisationsfenster; siehe Datenbankmigration.

04Zielumgebung

Die Landing Zone entsteht als Code, nicht per Hand

Bevor die erste Welle startet, steht das Ziel: Netzwerk, Berechtigungen und Grundkonfiguration sind per Infrastructure as Code bereitgestellt und getestet. Das macht die Zielumgebung wiederholbar und prüfbar, und eine Welle beginnt nie auf einem Zustand, den niemand mehr nachvollziehen kann.

  • OpenTofu oder Terraform für die Landing Zone
  • Ansible für wiederkehrende Serverkonfiguration
  • Netz und Berechtigungen vor Wellenbeginn getestet
Nahaufnahme von Server-Einschüben in einem Rack, ein Einschub teilweise herausgezogen, in blauem Licht

05Eine Welle im Überblick

Sieben Schritte von der Bereitschaft bis zur Stilllegung

Jede Migrationswelle durchläuft dieselben Checkpoints. Bis zum Rückfall-Entscheidungspunkt nach dem Cutover ist ein Zurückschalten ohne Datenverlust möglich.

Ablauf einer Migrationswelle mit Rückfall-Entscheidungspunkt Sieben Schritte einer Migrationswelle von Bereitschaft bis Stilllegung der Quelle; bis zum Rückfall-Entscheidungspunkt ist ein Rückweg möglich. Eine Migrationswelle in sieben Schritten Jeder Schritt hat ein Kriterium; bis zum Rückfall-Entscheidungspunkt bleibt der Rückweg offen. 1234567 Bereitschaft Datenvor-abkopie Go/No-Go Cutover Rückfall-Entscheidung Abnahme Still-legung IaC, Backup,Rollback geprüft Änderungsrategemessen Kriterien, Nameund Uhrzeit Quelle read-only,Umschaltung Zeitpunkt derletzten Umkehr Tests, Backupund Restore nach Be-obachtung Rückweg offen: Zurückschalten ohne Datenverlust Danach: anderer Wiederherstellungsweg Vorlage je Welle. Die Stilllegung der Quelle folgt erst nach einer vereinbarten Beobachtungszeit.
Ablauf einer Migrationswelle mit Rückfall-Entscheidungspunkt Sieben Schritte einer Migrationswelle von Bereitschaft bis Stilllegung der Quelle; bis zum Rückfall-Entscheidungspunkt ist ein Rückweg möglich. Eine Migrationswellein sieben Schritten Jeder Schritt hat ein Kriterium; bis zumRückfall-Entscheidungspunkt bleibt derRückweg offen. 1234567 BereitschaftDatenvorabkopieGo/No-GoCutoverRückfall-EntscheidungAbnahmeStilllegung IaC, Backup, Rollback geprüftÄnderungsrate gemessenKriterien, Name und UhrzeitQuelle read-only, UmschaltungZeitpunkt der letzten UmkehrTests, Backup und Restorenach Beobachtung Rückweg offen: Zurückschaltenohne Datenverlust Danach: andererWiederherstellungsweg Vorlage je Welle. Die Stilllegung der Quellefolgt erst nach einer vereinbartenBeobachtungszeit.

Prinzip

Wohin zurückgeschaltet wird, steht fest, bevor umgeschaltet wird

Der Rollback-Weg wird beschrieben und als Trockenlauf geprüft, die Entscheidung „weiter oder zurück“ mit Namen und Uhrzeit dokumentiert. Nach dem Rückfall-Entscheidungspunkt gilt ein anderer Wiederherstellungsweg, und auch der ist vorher benannt.

06Wellenplan

Was wir pro Welle festhalten und abhaken

Jede Welle beginnt mit einem Kopf: Systeme, Eigentümer aus Fachbereich und Technik, Abhängigkeiten zu früheren und späteren Wellen, Wartungsfenster und Kommunikationsplan. Danach folgen die Checkpoints, an denen Sie später nachvollziehen können, ob die Welle planmäßig lief.

  • Bereitschaft: Zielumgebung per IaC bereitgestellt, Netz und Berechtigungen getestet, Backup der Quelle verifiziert, Rollback-Weg beschrieben und als Trockenlauf geprüft.
  • Datenvorabkopie: Erstsynchronisation abgeschlossen, Änderungsrate gemessen, Dauer des finalen Abgleichs bekannt.
  • Go/No-Go: Kriterienliste abgearbeitet, Entscheidung mit Namen und Uhrzeit dokumentiert.
  • Cutover: Quelle schreibgeschützt, finaler Datenabgleich, Umschaltung (DNS, Lastverteilung, Verbindungsdaten), Rauchtest.
  • Rückfall-Entscheidungspunkt: Zeitpunkt, bis zu dem ohne Datenverlust zurückgeschaltet werden kann; danach gilt ein anderer Wiederherstellungsweg.
  • Abnahme: Funktions-, Leistungs- und Integrationstests nach den vereinbarten Kriterien, Backup- und Restore-Test auf der Zielumgebung.
  • Stilllegung der Quelle: erst nach einer vereinbarten Beobachtungszeit, mit Datenarchivierung nach Ihren Vorgaben.

07Zielplattformen

AWS, Azure, Google Cloud oder STACKIT als Ziel

Wir migrieren auf AWS, Azure, Google Cloud und STACKIT. Eine Übersicht nach Anbieter finden Sie unter Cloud-Plattformen.

Für die Vorbereitung einer Migration nach STACKIT gibt es das separate Produkt StackToIT: Nach den Angaben auf stacktoit.com liest es Terraform- oder OpenTofu-Code beziehungsweise VMware-RVTools-Exporte und erzeugt daraus eine Service-Zuordnung, Entwürfe für Zielarchitektur und Terraform sowie einen Migrationsplan zur Prüfung durch Architekten. Es ersetzt weder Bestandsaufnahme noch Entscheidung und ist keine Voraussetzung für unsere Beratung.

StackToIT ansehen

Nahaufnahme leuchtender Glasfasern in Blau und Grün vor dunklem Hintergrund

08Ihr Beitrag

Was wir von Ihnen für einen belastbaren Start brauchen

  • Zugriff auf Systeme und Dokumentation für die Bestandsaufnahme
  • Ansprechpartner je Anwendung, aus Fachbereich und Technik
  • Die harten Termine
  • Freigabezeiten für Wartungsfenster
  • Klärung von Lizenz- und Vertragsfragen für Software, die an Hardware, Standort oder Anbieter gebunden ist

09Zugriff und Recht

Zugriffe, Verschlüsselung, Rechtsprüfung: wo die Grenzen liegen

  • Zugriffe auf Zeit

    Migrationszugriffe sind zeitlich begrenzt und rollenbasiert; Zugangsdaten bleiben bei Ihnen.

  • Verschlüsselte Übertragung

    Daten werden bei der Übertragung verschlüsselt; Schlüssel und Standort der Daten legen wir vor Beginn fest.

  • Technik bei uns, Recht bei Ihnen

    Wir bewerten technische Sicherheitsmaßnahmen im Ziel; die Rechtsprüfung (etwa Auftragsverarbeitung) bleibt bei Ihrem Datenschutz. Siehe Cloud Security.

  • Kein Ein-Klick-Versprechen

    Automatisierung beschleunigt, ersetzt aber weder Assessment noch Abnahme.

10Passung

Wann ein Migrationsprojekt mit uns noch nicht startklar ist

Das passt

  • Es gibt einen Verantwortlichen je Anwendung, der Abnahmekriterien festlegen kann.
  • Termine dürfen sich nach der Bestandsaufnahme richten.
  • Die Migration erfolgt ohne gleichzeitige Neuentwicklung der Funktion.

Das passt nicht

  • Sie wollen einen festen Endtermin zugesagt bekommen, bevor das Inventar existiert. Termine geben wir nach der Bestandsaufnahme.
  • Die Anwendung soll gleichzeitig in der Funktion neu entwickelt werden. Das trennen wir in zwei Vorhaben, siehe Software.
  • Sie suchen eine reine Wiederverkaufs- oder Hosting-Leistung.

Nennen Sie uns Auslöser, Termin und Systemlandschaft

Eine grobe Beschreibung reicht für den Start; daraus entsteht die kurze Bestandsaufnahme, auf der das Angebot beruht. Alle Leistungen im Überblick: Leistungen.

Projekt anfragen