Cloud-Migration: Die richtige Strategie für Unternehmen

AWS beschreibt sieben Migrationsstrategien, bekannt als "7 Rs" [W1]. Microsoft nutzt ein sehr ähnliches Raster mit Retire, Retain, Rehost, Replatform, Refactor, Rearchitect, Rebuild und Replace und ordnet jeder Strategie einen geschäftlichen Treiber zu [W2]. Zusammengefasst:

Ein Hinweis aus dem AWS-Leitfaden ist für große Vorhaben besonders wichtig: Refactoring wird für große Migrationen nicht empfohlen, weil es die Anwendung während der Migration modernisiert und damit die komplexeste Strategie ist. AWS empfiehlt stattdessen, zunächst per Rehost, Relocate oder Replatform zu migrieren und erst danach zu modernisieren [W1].

Google gliedert eine Migration in vier Phasen [W3]:

1. Assess: Bestand und Abhängigkeiten der Anwendungen erfassen, Anforderungen klären, Gesamtkosten (TCO) berechnen und Leistungsbenchmarks festlegen. 2. Plan: Die Grundinfrastruktur schaffen, also Identitäten, Organisations- und Projektstruktur sowie Netzwerk, und die Anwendungen in eine priorisierte Migrationsreihenfolge bringen. 3. Deploy: Den Umzug der Arbeitslasten entwerfen, umsetzen und durchführen, bei Bedarf die Infrastruktur nachschärfen. 4. Optimize: Nach dem Umzug die Umgebung optimieren.

Die Assess-Phase entscheidet über den Erfolg. Hier wird festgelegt, welche Anwendung welche der sieben Strategien bekommt. Wer diese Zuordnung überspringt, migriert alles per Lift and Shift und nimmt die Ineffizienzen der alten Umgebung mit in die Cloud.

Viele Strategieleitfäden gehen stillschweigend davon aus, dass das Ziel ein bestimmter Hyperscaler ist. Für europäische Unternehmen ist die Wahl der Zielplattform jedoch selbst eine Entscheidung. Eine Masterarbeit der LUT University hat die Migration einer AWS-Referenzarchitektur zu OVHcloud, Hetzner und Scaleway anhand der Anbieterdokumentation bewertet. Ergebnis: Container-Orchestrierung, skalierbare Rechenleistung, Speicher und Automatisierung per Infrastructure as Code stehen bei allen drei Anbietern zur Verfügung. Abstriche gibt es bei globaler Präsenz und integrierten Werkzeugen, die sich oft mit Open-Source-Werkzeugen nachbilden lassen, allerdings mit mehr Einrichtungsaufwand [S34].

Dieselbe Arbeit nennt Managed Services und anbieterspezifische Schnittstellen als Hauptquelle der Abhängigkeit [S34]. Daraus folgt eine praktische Regel für die Strategiewahl: Je stärker eine Anwendung proprietäre Plattformdienste nutzt, desto eher passt Replatform oder Refactor statt Rehost, und desto wichtiger ist die Frage, ob man sich mit der Migration neu an einen Anbieter bindet. Einen Überblick über die Kriterien zur Anbieterwahl gibt unser Beitrag zu europäischen Cloud-Anbietern. Die strategischen Kosten von Abhängigkeit beschreibt Concentration Risk, Lock-In, and Exit (englisch).

Jede Migration ist auch der Beginn einer möglichen nächsten. Der EU Data Act stärkt dabei die Position der Kunden. Verträge mit Anbietern von Datenverarbeitungsdiensten müssen den Wechsel auf Verlangen zu einem anderen Anbieter oder in die eigene Infrastruktur ermöglichen, mit einer Übergangsfrist von höchstens 30 Kalendertagen (Artikel 25) [W4]. Ab dem 12. Januar 2027 dürfen für den Wechsel keine Wechselentgelte mehr erhoben werden, bis dahin nur reduzierte Entgelte in Höhe der direkten Kosten (Artikel 29) [W4].

Für die Migrationsstrategie bedeutet das: Dokumentieren Sie bereits in der Plan-Phase, wie Daten und Arbeitslasten wieder exportiert werden könnten, und prüfen Sie die Ausstiegsklauseln der Zielplattform. Was die Abschaffung der Wechselentgelte löst und was nicht, erklärt unser Beitrag EU Data Act: Cloud Switching Fees End 12 Jan 2027 (englisch).

Alles per Lift and Shift. Rehost ist schnell, übernimmt aber jede Überdimensionierung. Die Assess-Phase sollte vorher klären, was stillgelegt oder ersetzt werden kann [W1][W3].

Refactoring mitten in der großen Migration. AWS rät davon ab und empfiehlt, erst zu migrieren und dann zu modernisieren [W1].

Keine TCO-Rechnung. Google sieht die Berechnung der Gesamtkosten ausdrücklich in der Assess-Phase vor [W3]. Ohne sie bleibt unklar, ob sich die Migration lohnt und welches Ziel am günstigsten ist.

Datenresidenz vergessen. Anforderungen an den Speicherort können ein Grund sein, eine Anwendung zunächst beizubehalten [W1] oder gezielt auf eine europäische Plattform zu setzen.

Keinen Exit-Plan. Ohne dokumentierten Ausstieg entsteht mit der Migration die nächste Abhängigkeit [W4][S34].

Die Strategien und Phasen stammen aus den Leitfäden von AWS, Microsoft und Google, Stand 15. Oktober 2026, und sind auf die jeweilige Zielplattform ausgerichtet. Die Bewertung europäischer Anbieter beruht auf einer einzelnen qualitativen Studie ohne Lasttests [S34]. Die Darstellung des Data Act ist eine operative Einordnung, keine Rechtsberatung.

Eine gute Cloud-Migrationsstrategie ist eine Liste von Einzelentscheidungen: Für jede Anwendung die passende der sieben Strategien, in vier klaren Phasen umgesetzt, mit einer bewusst gewählten Zielplattform und einem dokumentierten Ausstieg.

Atomity unterstützt genau die Entscheidung vor dem Umzug. Wir vergleichen für jede Arbeitslast, wo sie unter Kosten-, Compliance- und Souveränitätsgesichtspunkten am besten läuft, über AWS, Azure und Google Cloud ebenso wie über IONOS, STACKIT, OVHcloud, Hetzner und Open Telekom Cloud, und machen ungenutzte Ressourcen sichtbar, bevor sie mit umziehen. Den Ausgangspunkt liefert die kostenlose Cloud-Kostenanalyse.