Cloud-Migration: Bestehendes verlagern, ohne alles kaputt zu machen

Eine Cloud-Migration geht selten beim Kopieren kaputt. Sie geht in dem Moment kaputt, in dem man glaubt, fertig zu sein. Im Juli 2026 war die Festplatte unseres Servers voll, auf dem rund ein Dutzend Dienste laufen, darunter das CRM von Palmora Property, einem Immobilienportal, das wir für unseren Kunden betreiben, und seine Datenbanken waren in Gefahr: Das CRM legte die Fotos der Objekte selbst dort ab. Wir haben sie in einen Objektspeicher verlagert, ohne eine Datei zu verlieren; die Falle lag in Zugangsschlüsseln, die nicht bis zur Anwendung gelangten.

Migrieren heißt hier, das zu verlagern, was bereits läuft (Anwendungen, Daten, Dateien, Domainnamen), zu einem großen Anbieter, zu einem anderen Hoster oder zurück auf einen eigenen Server. Hier ist die Methode, die wir Workload für Workload anwenden, für Teams von 20 bis 500 Personen. Sie setzt voraus, dass das Infrastrukturfundament, das diese Workloads aufnehmen wird, bereits existiert.

Kurz gesagt

• Inventarisieren Sie auch, was bei Ihren Nutzern liegt: Sitzung, installierte App, Benachrichtigungen.
• Wählen Sie eine Strategie pro Workload und modernisieren Sie nach der Migration, nicht währenddessen.
• Kopieren, testen, vergleichen, und erst dann löschen.
• Schreiben Sie die Bedingungen für den Rückweg vor dem Start auf und behalten Sie den alten Weg für die Dauer der Bewährung.
• Ein gewolltes Hybridmodell ist kein Scheitern.

Was muss man vor der Migration inventarisieren?

Der Migrationsleitfaden von Google Cloud teilt eine Migration in vier Phasen: bewerten, planen, bereitstellen, optimieren. Die erste dient dazu, „understand your app and environment inventory, identify app dependencies and requirements, perform total cost of ownership calculations, and establish app performance benchmarks“: also das Inventar von Anwendungen und Umgebung zu verstehen, Abhängigkeiten und Anforderungen zu erkennen, die Gesamtbetriebskosten zu berechnen und Leistungsreferenzen festzulegen.

Die Abhängigkeiten bestimmen die Reihenfolge. Laut dem Planungsleitfaden von Microsoft gilt: „dependencies between workloads cause service disruptions if not migrated together“, und jede Tranche muss mitnehmen, was ihre Anwendungen brauchen, „including supporting infrastructure such as load balancers, DNS records, or caching layers“, also auch Load Balancer, DNS-Einträge oder Cache-Schichten.

Inventarisieren Sie auch, was Ihre Nutzer auf ihrer Seite behalten. Für einen Browser ist eine andere Adresse eine andere Anwendung: Als Challenge Us, eine von uns entwickelte App für Gruppenchallenges, im September 2026 die Adresse wechselte, blieben Sitzung, Einstellungen, installierte App und Benachrichtigungen bei der alten.

Welche Strategie für welchen Workload?

Der Leitfaden von AWS zu großen Migrationen ordnet die Optionen in sieben Strategien, die „7 Rs“:

• Retire: stilllegen oder archivieren, was nicht mehr gebraucht wird.
• Retain: vor Ort behalten, vorerst oder dauerhaft.
• Rehost: unverändert umziehen, das „lift and shift“.
• Relocate: zahlreiche Server auf die Cloud-Version ihrer Plattform übertragen.
• Repurchase: durch eine andere Version oder ein anderes Produkt ersetzen.
• Replatform: mit etwas Optimierung unterwegs verlagern.
• Refactor or re-architect: die Architektur überarbeiten, um cloud-eigene Funktionen zu nutzen.

Für eine große Migration rät AWS von der Neugestaltung ab, „because it involves modernizing the application during the migration“, und empfiehlt „rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete“: erst umziehen, verlagern oder die Plattform wechseln, dann nach Abschluss der Migration modernisieren.

Die drei von uns durchgeführten Migrationen lassen sich diesen Kategorien zuordnen: die tägliche Synchronisierung von Palmora Property, ohne Änderung ihrer Schritte auf unseren Server umgezogen; die Dateiablage seines CRM, per Konfiguration auf eine andere Plattform gewechselt, ohne den Code anzufassen; die Seiten von Challenge Us, zu einem anderen Hoster umgezogen, ohne neu geschrieben zu werden. Wir haben keine Migration zu AWS, Google Cloud oder Azure durchgeführt: Ihre Leitfäden dienen uns hier als gemeinsames Vokabular, unabhängig vom Ziel.

Warum kopieren statt verschieben?

Kopieren lässt das Original unverändert, solange die Kopie sich nicht bewährt hat: Der Rückweg passt dann in eine Konfigurationszeile. Für die Dateien des CRM von Palmora Property haben wir nach einer Erkundung mit reinem Lesezugriff vier Schutzvorkehrungen getroffen:

• Ein eigener Speicherbereich: Der Bereich für die Bilder der Website wird von verwaisten Dateien bereinigt, und in einem gemeinsamen Bereich hätte diese Bereinigung die Dateien des CRM gelöscht.
• Ein eigener Zugangsschlüssel, auf diesen Bereich beschränkt, widerrufbar, ohne die Website zu berühren.
• Dateien, die privat bleiben, ausgeliefert vom CRM hinter seiner eigenen Authentifizierung.
• Eine Sicherung jeder Konfigurationsdatei, der alte Wert als Kommentar behalten: Er ist der Rückweg.

Dieses CRM ist Twenty: Wir haben es seit Anfang 2025 in Produktion und tragen zum Projekt bei. Es kann seine Dateien in einem S3-kompatiblen Speicher ablegen, also einem, der dieselbe Schnittstelle spricht wie der Speicherdienst von Amazon: Wir haben das in seinem Code überprüft. Die Falle lag woanders: Die Konfiguration der Container übermittelte nur einen Teil der Speichereinstellungen, ohne die Zugangsschlüssel. Sie mussten dem Hauptdienst und dem Dienst für Hintergrundaufgaben hinzugefügt werden.

Wie prüft man vor der Umstellung und vor dem Löschen?

Vor der Umstellung wurde der Zugriff auf den neuen Speicher lesend und schreibend getestet, die Kopie lief fehlerfrei durch, und die neue Konfiguration wurde validiert. Nach der Umstellung drei Tests, und ein vierter nach dem Löschen:

1. 01Lesen

   Ein Objekt mit Fotos öffnet sich, ausgeliefert vom neuen Speicher.

2. 02Schreiben

   Ein hinzugefügtes Bild landet im neuen Speicher, und der alte Ordner bleibt unverändert.

3. 03Integrität

   Der Vergleich beider Seiten findet keinen Unterschied. Dieser Test erlaubt das Löschen.

4. 04Endgültiger Nachweis

   Ist der alte Ordner geleert, kommt jedes noch angezeigte Bild zwangsläufig aus dem neuen Speicher.

Eine Einschränkung: Der Vergleich betraf die Namen und Größen der Dateien, in nur einer Richtung, ohne Prüfsumme des Inhalts. Er zeigt, dass nichts fehlt, nicht, dass jedes Byte identisch ist.

Wie stellt man mit einem Rückweg um?

Der Rückweg wird vor dem Start entschieden. Microsoft schreibt es ausdrücklich: „Always establish rollback criteria and procedures before initiating any migration or deployment.“ Seine Auslöser sind messbar, wie „CPU usage limits, response time thresholds, or error rates“, also Grenzwerte für CPU-Last, Antwortzeiten oder Fehlerquoten, und das Verfahren wird getestet: „Verify that the rollback procedure restores the system to a stable, known-good state.“

Bei einem Domainnamen hängt alles von der Reihenfolge der Schritte ab. Als Challenge Us die Adresse wechselte, hätte eine Weiterleitung die App eingefroren: Ihr Service Worker, das kleine Programm, das sie aus dem Cache des Browsers ausliefert, aktualisiert sich nie über eine Weiterleitung. Beide Adressen lieferten daher dieselbe Version aus, und die alte bot den Umzug erst an, als die neue bereit war.

Als Challenge Us danach den Hoster wechselte, geschah das in vier Schritten.

Unsere Regel seitdem: den Eintrag behalten und über eine Routing-Regel gehen, oder ihn löschen und den Namen gleich danach anbinden, nie das eine ohne das andere.

Wie lange behält man den alten Weg?

Eine Migration führt nicht immer in die Cloud. Seit dem 23. Juli 2026 läuft die tägliche Synchronisierung, die die Website von Palmora Property aus seinem CRM speist, auf unserem eigenen Server und nicht mehr in einem Online-Dienst für Continuous Integration. Das CRM ist dort lokal, die Caches liegen auf der Festplatte, Schritte und Zeitplan haben sich nicht geändert, und eine Sperre verhindert, dass sich zwei Ausführungen überschneiden.

Der alte Weg ist geblieben, als manuelle Reserve. Aber eine Reserve altert: Ihr Cache ist seit Juli eingefroren, sie würde Tausende von Objekten erneut prüfen und könnte stundenlang laufen. Bei Challenge Us wird die alte Adresse nie abgeschaltet: Sie kostet nichts, und sie bringt die bereits installierten Apps zurück. Behalten Sie den alten Weg also, solange ihn noch jemand nutzt, und prüfen Sie von Zeit zu Zeit, ob er noch funktioniert.

Wann löschen, und was danach messen?

Das Löschen kommt zuletzt, nach dem Vergleich, und unter Schutz: ein exakter Pfad und die Prüfung, dass der Ordner wirklich das enthält, was man erwartet. Danach bleibt der Rückweg möglich, ändert aber seine Art: etwa eine Stunde erneutes Kopieren, die Konfiguration wiederhergestellt, ein Neustart. Unser Artikel darüber, was bei den Backups eines eigenen Servers wirklich kaputtgeht, erinnert daran: Eine Kopie ist nur etwas wert, wenn man sie wieder einspielen kann.

Messen Sie danach.

Challenge Us misst seinerseits, wer die App noch über die alte Adresse öffnet.

Einen Teil vor Ort behalten: Ist Hybrid ein Scheitern?

Nein, wenn es gewollt ist. AWS macht aus „Retain“ eine vollwertige Strategie und nennt unter seinen Fällen der Neugestaltung eine Datenbank, deren Tabellen teilweise, „such as customer information, patient, or patient diagnosis tables“, aus Gründen der Sicherheit und Compliance vor Ort bleiben. Microsoft verlangt, zu dokumentieren, warum eine Komponente vor Ort bleibt, und den Zwischenzustand zu begrenzen: „Minimize split-environment operation time.“

Diese beiden Kundenprojekte sind hybrid, aus freier Wahl. Das CRM von Palmora Property läuft auf unserem Server, seine Dateien liegen in einem Objektspeicher, und eine wöchentliche Bereinigungsaufgabe bleibt vorerst im Continuous-Integration-Dienst. Challenge Us hat für seine Seiten den Hoster gewechselt, aber seine Datenbank, seine Konten und seine Serverfunktionen haben sich nicht bewegt. Für die Zukunft sagt unsere Analyse der europäischen Abhängigkeit von der amerikanischen Cloud, was das europäische Recht an den Kosten eines Anbieterwechsels ändert.

Die Checkliste vor der Umstellung

• Die Kopie ist fehlerfrei abgeschlossen, und das Original ist unverändert.
• Die neuen Einstellungen erreichen alle betroffenen Dienste, nicht nur den ersten.
• Lesen und Schreiben sind am neuen Ziel getestet.
• Die Bedingungen für den Rückweg sind aufgeschrieben, mit dem Namen der Person, die entscheidet.
• Der alte Weg bleibt offen, und Sie wissen, für wie lange.
• Ein Signal warnt, wenn der neue Weg nicht mehr läuft.

Womit anfangen

Listen Sie auf, was sich bewegen muss, mit einer Strategie und ihrer Rückwegbedingung für jede Zeile. Beginnen Sie mit einem Workload, dessen Rückweg einfach ist, zum Beispiel Dateien. Wenn Ihre Werkzeuge ihre Abonnements für einen eigenen Server verlassen sollen, verlagert unser SaaS-Ausstieg sie einzeln, mit geprüften Daten und vorgesehenem Rückweg. Wenn das Ziel ein großer Anbieter oder eine europäische Cloud ist, schreiben Sie uns, was sich bewegen muss und wohin Sie es bringen wollen.

Häufige Fragen

Quellen

1. Der Migrationsleitfaden von Google Cloud (neuer Tab)docs.cloud.google.com
2. Dem Planungsleitfaden von Microsoft (neuer Tab)learn.microsoft.com
3. Der Leitfaden von AWS zu großen Migrationen (neuer Tab)docs.aws.amazon.com