1. Ziel und Umfang vor der Technik festlegen
Beginnen Sie mit dem Auslöser: Geht es um besser kalkulierbare Kosten, mehr Einfluss auf die Umgebung oder eine geringere Abhängigkeit von einzelnen Plattformfunktionen? Diese Ziele führen nicht automatisch zur gleichen Architektur. Beschreiben Sie deshalb, welche Anwendung zurückgeführt werden soll und woran die spätere Abnahme gemessen wird.
Dokumentieren Sie auch die Grenzen. Welche Funktionen bleiben vorerst in der Cloud? Welche Unterbrechung verträgt das Geschäft? Welche Datenänderungen dürfen im Fehlerfall höchstens fehlen? Die maximal tolerierte Wiederherstellungszeit und der maximal tolerierte Datenverlust werden häufig als RTO und RPO bezeichnet. Legen Sie passende Werte für Ihren konkreten Dienst fest, statt Standardwerte zu übernehmen.
2. Abhängigkeiten und Exportmöglichkeiten aufnehmen
Erstellen Sie eine Übersicht aus Anwendung, Datenbank, Dateispeicher, Anmeldung, Aufgabenplanung und externen Schnittstellen. Ergänzen Sie DNS, Zertifikate, Versanddienste und technische Konten. Wichtig ist nicht nur, ob eine Komponente vorhanden ist, sondern wer sie anspricht und mit welchen Rechten. Eine isolierte Serverliste zeigt diese Beziehungen häufig nicht.
Prüfen Sie Exportformate und Nutzungsrechte früh. Ein Datenexport ersetzt weder den Quellcode einer fremden SaaS-Lösung noch die Erlaubnis, deren Software selbst zu betreiben. Bei eigenen Anwendungen können plattformspezifische Funktionen eine Anpassung verlangen. Kennzeichnen Sie solche Stellen als offene Entwicklungsaufgabe und kalkulieren Sie deren Ersatz vor der Umstellung.
Fachquelle: ISACA Germany: Positionspapier Cloud Exit (2026) (externe Seite, neuer Tab). Die Projektbeispiele und Entscheidungshilfen sind redaktionelle Einordnungen von JustBeDigital.
3. Eine betreibbare Zielumgebung entwerfen
Planen Sie nicht nur Rechenleistung und Speicher. Zur Zielumgebung gehören Netzwerkgrenzen, Berechtigungen, Geheimnisverwaltung, Updates, Sicherungen und Überwachung. Der Zugriff für die Migration sollte zeitlich begrenzt und auf das Erforderliche eingeschränkt sein. Halten Sie fest, wer nach der Übergabe über administrative Rechte verfügt.
Klären Sie den laufenden Betrieb, bevor der erste produktive Dienst umzieht. Wer bearbeitet Alarme? Wer spielt Sicherheitsupdates ein? Wie erfolgt die Wiederherstellung, wenn die zuständige Person ausfällt? Ein technisch sauberer Aufbau mit ungeklärten Zuständigkeiten schafft eine neue Abhängigkeit. Diese Fragen gehören in die Leistungs- und Betriebsvereinbarung.
4. Mit einer abgegrenzten Anwendung erproben
Ein Pilot sollte überschaubar sein und trotzdem typische Eigenschaften des späteren Betriebs enthalten. Nur eine leere Testseite zu verschieben beweist beispielsweise nicht, dass Anmeldung, Dateizugriff oder Hintergrundaufgaben der eigentlichen Anwendung funktionieren. Nutzen Sie möglichst synthetische oder ausreichend geschützte Testdaten und begrenzen Sie Kopien produktiver Daten.
Prüfen Sie die fachlichen Wege: anmelden, Datensatz anlegen, Berechtigungen wechseln, Dateien öffnen und einen typischen Folgeprozess ausführen. Ergänzen Sie den Wiederanlauf nach einer Unterbrechung und eine Wiederherstellung aus der Sicherung. Halten Sie das Ergebnis und verbleibende Fehler fest. Ein gestarteter Prozess ist noch keine fachliche Abnahme.
5. Datenübernahme und Schreibzugriffe koordinieren
Legen Sie fest, wie die erste Kopie und der abschließende Abgleich entstehen. Prüfen Sie nicht nur Dateimengen oder Zeilenzahlen, sondern auch Beziehungen, Zeichensätze, Zeitangaben und Zugriffsbeschränkungen. Ein gleich großer Datenbestand kann fachlich trotzdem unvollständig sein. Für wichtige Abläufe braucht es deshalb konkrete Prüffälle.
Während der Umschaltung muss klar sein, welche Umgebung Schreibzugriffe annehmen darf. Zwei voneinander abweichende Datenbestände lassen sich nicht durch einen DNS-Wechsel zuverlässig zusammenführen. Ein Wartungsfenster, ein Schreibstopp oder ein geeignetes Synchronisationsverfahren hängt von der Anwendung ab. Die gewählte Methode und ihre Einschränkungen werden vorab festgelegt.
6. Umschalten mit Freigabe und Rückfallplan
Ein Umschaltplan enthält Reihenfolge, Verantwortliche, Prüfschritte und Abbruchkriterien. Dazu gehören der letzte Datenabgleich, die Änderung von Verbindungen und die anschließende Funktionsprüfung. Die AWS-Anleitung zum Cutover behandelt solche Schritte für eine Migration in die Cloud. Die hier beschriebene Anwendung auf die Rückführung ist eine technische Übertragung dieser allgemeinen Planungsprinzipien, keine Anleitung für einen automatischen Rückweg.
Ein Rückfallplan muss neue Daten nach der Umschaltung berücksichtigen. Einfach auf den alten Server zurückzuzeigen kann zwischenzeitlich erfasste Änderungen verlieren. Definieren Sie, bis wann ein Rückweg möglich ist, wer ihn auslösen darf und wie seit der Umschaltung entstandene Daten erhalten werden. Ist das nicht sicher möglich, muss die Einschränkung vor der Freigabe bekannt sein.
Fachquelle: AWS Prescriptive Guidance: Cutover stage (externe Seite, neuer Tab). Die Projektbeispiele und Entscheidungshilfen sind redaktionelle Einordnungen von JustBeDigital.
7. Stabilisieren und erst danach abschalten
Beobachten Sie nach dem Wechsel die vereinbarten Betriebsmerkmale und die fachlichen Prozesse. Lassen Sie sich die Anwendung von den zuständigen Anwendern abnehmen. Erst nach dieser Phase werden alte Ressourcen geordnet beendet. Prüfen Sie dafür auch Sicherungskopien, Zugangsdaten, technische Konten und weiterlaufende Verträge.
Zur Übergabe gehören eine verständliche Systemübersicht, Zuständigkeiten, Wiederherstellungsanleitung und die vereinbarte Pflege. Die Cloud Repatriation ist dann abgeschlossen, wenn der vereinbarte Zielbetrieb überprüfbar funktioniert und die Restarbeiten dokumentiert sind. Ob JustBeDigital nur die Planung oder zusätzlich Teile der Umsetzung übernimmt, wird für das jeweilige Projekt gesondert festgelegt.
- Abnahmekriterien und Zuständigkeiten dokumentiert
- Fachliche Abläufe und Wiederherstellung geprüft
- Alte Zugänge und Restverträge berücksichtigt
- Betriebsdokumentation an die zuständige Stelle übergeben
Häufige Fragen
01Geht Cloud Repatriation ohne Ausfallzeit?
Das hängt von Anwendung, Datenhaltung und Synchronisationsmöglichkeiten ab. Ein Wartungsfenster kann nötig sein. Eine allgemeine Zusage für unterbrechungsfreie Migration wäre ohne Prüfung nicht belastbar.
02Muss sofort die ganze Cloud verlassen werden?
Nein. Eine abgegrenzte Anwendung oder einzelne Bestandteile können einen sinnvollen Anfang bilden. Verbleibende Verbindungen, Kosten und Zuständigkeiten müssen dabei weiterhin berücksichtigt werden.