Ein Leitfaden zur Cloud-Migration für Unternehmen – von der Bewertung bis zur Umstellung

Unternehmen migrieren selten nur einmal. Sie migrieren ein erstes System, lernen daraus und migrieren dann die nächsten zehn. Ein Playbook hält das Gelernte fest, damit die zweite Welle schneller und sicherer verläuft als die erste: wie Systeme bewertet werden, wie die Landing Zone aussieht, wie eine Umstellung abläuft und was „abgeschlossen“ bedeutet. Diesen Leitfaden verwenden wir als Ausgangspunkt mit unseren Kunden; er sollte an Ihr Unternehmen angepasst und nicht wörtlich befolgt werden.

Zwei Grundsätze ziehen sich durch. Erstens: Migrieren Sie die Geschäftsfunktion, nicht den Server. Die Frage ist, wie eine Anwendung und ihre Daten den Nutzern weiterhin dienen, nicht, wie eine virtuelle Maschine kopiert wird. Zweitens: Halten Sie jeden Schritt umkehrbar, bis er bewusst endgültig gemacht wird.

Die Wahl der Region steht an erster Stelle. Eine Region im eigenen Land, sofern vorhanden, bietet mehrere Availability Zones für Ausfallsicherheit und geringe Latenz für lokale Nutzer. Die AWS-Region Asia Pacific (Bangkok) (ap-southeast-7) ist ein Beispiel: Sie bietet Unternehmen mit Nutzern in Thailand eine Wahlmöglichkeit, die es über den größten Teil der Cloud-Ära nicht gab, statt das Land von Singapur aus zu bedienen. Für latenzkritische Systeme und für Unternehmen, deren Richtlinien oder Aufsichtsbehörden Daten lieber im Land halten, ist eine Region im eigenen Land der übliche Ausgangspunkt.

Zwei Vorbehalte gelten. Neuere Regionen starten nicht mit allen Diensten; prüfen Sie für jeden verwalteten Dienst im Design die regionale Dienstliste, bevor Sie sich festlegen, und bereiten Sie eine Alternative vor (einen anderen Dienst oder eine andere Region für diese Komponente). Datenresidenz ist zudem zuerst eine Richtlinienentscheidung und erst dann eine technische: Datenschutzrecht wie das PDPA erlaubt grenzüberschreitende Übermittlungen unter Bedingungen, und Branchenaufsichten, etwa im Finanzsektor, können eigene Erwartungen haben. Halten Sie schriftlich fest, welche Datenkategorien im Land bleiben müssen und welche zur Notfallwiederherstellung ins Ausland repliziert werden dürfen, und lassen Sie dies von Rechts- und Compliance-Abteilung bestätigen. Hinterlegen Sie es anschließend als Regionsbeschränkungen in den Richtlinien des Unternehmens, damit eine falsch platzierte Ressource verhindert und nicht erst nachträglich entdeckt wird.

Die Notfallwiederherstellung verdient dieselbe Klarheit. Innerhalb einer Region schützen mehrere Availability Zones vor dem Ausfall eines Rechenzentrums. Zum Schutz vor einem regionalen Ereignis entscheiden Sie, ob eine zweite Region für Backups oder Standby zulässig ist, welche Region das sein soll und welche Wiederherstellungszeit und welchen Wiederherstellungspunkt das Unternehmen finanzieren will.

Alles in der Landing Zone, was sich als Code definieren lässt, sollte auch so definiert werden: Konten und Organisationsrichtlinien, Netzwerke und Routing, Identitäten und Rollen, Protokollierung und Audit-Trails, Verschlüsselungsschlüssel, Backup-Richtlinien, Budgets und Alarme. Terraform ist unser bevorzugtes Werkzeug, weil es deklarativ und anbieterunabhängig ist und sich im selben Pull-Request-Ablauf prüfen lässt wie Anwendungscode.

Einige Praktiken halten das Ganze beherrschbar. Speichern Sie den State remote mit Sperre, je ein State pro Umgebung und pro logischer Komponente, damit ein Fehler an einer Stelle keine andere beschädigen kann. Erstellen Sie kleine, klar benannte Module für wiederholt angelegte Elemente (ein Service mit Container-Definition, Load-Balancer-Regel, IAM-Rolle und Log-Gruppe) und versionieren Sie sie. Versehen Sie jede Ressource über ein zentrales Tagging-Modul mit Verantwortlichem, Umgebung, Anwendung und Kostenstelle, denn die spätere Kostenkontrolle hängt davon ab. Führen Sie bei jeder Änderung einen Plan aus, verlangen Sie ein Review und wenden Sie Änderungen aus einer Pipeline an statt vom Laptop. Erkennen Sie Drift nach Zeitplan und behandeln Sie manuelle Änderungen in der Konsole als Vorfälle, die abzugleichen sind, und nicht als neuen Normalzustand.

Das Ergebnis: Die Umgebung für Welle zwei ist ein Pull Request und kein Projekt.

Jedes Runbook hat einen Abschnitt zum Rollback, doch nur wenige Teams haben ihn je ausgeführt. Proben Sie die vollständige Umstellung mindestens einmal in einer Nicht-Produktionsumgebung mit denselben Personen, derselben Checkliste und auf Zeit, und proben Sie anschließend den Rollback. Legen Sie die Go/No-Go-Kriterien vor dem Stichtag fest (welche Tests bestanden sein müssen, welche Stakeholder bis wann bestätigen müssen) und benennen Sie die eine Person, die entscheidet. Bestimmen Sie den Point of No Return ausdrücklich: den Moment, ab dem neue Transaktionen nur noch im Ziel existieren und ein Rollback einen manuellen Datenabgleich bedeutet.

Kommunizieren Sie während der eigentlichen Umstellung nach festem Zeitplan und nicht erst, wenn etwas passiert: Eine Statusmeldung alle dreißig Minuten, auch wenn sie nur meldet, dass alles nach Plan läuft, hält das Unternehmen ruhig und das Team konzentriert. Führen Sie danach eine kurze Nachbesprechung durch, solange die Details noch präsent sind, und aktualisieren Sie das Playbook.