Cloud-Migration
Cloud-Migration bezeichnet die Verlagerung von Anwendungen, Daten und Infrastruktur aus dem eigenen Rechenzentrum in eine Cloud-Umgebung. Das Spektrum reicht vom unveränderten Umzug (Rehosting) bis zum Cloud-Native-Neuaufbau — welcher Weg trägt, hängt von Anwendung, Regulatorik und Wirtschaftlichkeit ab.
Migrationsstrategien im Überblick
Ein verbreitetes Ordnungsschema unterscheidet sechs Strategien — die „6 R“:
| Strategie | Vorgehen | Typischer Einsatz |
|---|---|---|
| Rehost (Lift-and-Shift) | Anwendung unverändert auf Cloud-Infrastruktur verschieben | schneller Rechenzentrums-Ausstieg, wenig Nutzen darüber hinaus |
| Replatform | punktuelle Anpassungen, z. B. Wechsel auf eine Managed Database | Betriebsaufwand senken bei moderatem Aufwand |
| Refactor / Re-Architect | Umbau auf eine Cloud-Native-Architektur | strategische Kernsysteme mit langer Restlebensdauer |
| Repurchase | Ablösung durch ein SaaS-Produkt | Standardfunktionen ohne Differenzierungswert |
| Retire | Anwendung abschalten | ungenutzte oder redundante Systeme |
| Retain | bewusst (vorerst) im Bestand belassen | Systeme mit hoher Kopplung, regulatorischen Hürden oder naher Ablösung |
In realen Portfolios kommt fast immer eine Mischung zum Einsatz — die Strategie wird pro Anwendung entschieden, nicht pauschal für die gesamte Landschaft.
Mehr als ein Umzug: Cloud-Native als Zielbild
Die versprochenen Vorteile der Cloud — Elastizität, kürzere Release-Zyklen, geringerer Betriebsaufwand — entstehen nicht durch den Ortswechsel, sondern durch die Architektur: Container und Orchestrierung (Docker, Kubernetes), Managed Services statt Eigenbetrieb, Infrastruktur als Code (etwa Terraform), automatisierte CI/CD-Pipelines und häufig eine Zerlegung in Microservices oder eventgetriebene Systeme.
Ein reiner Lift-and-Shift übernimmt dagegen Dimensionierung und Architektur des Rechenzentrums 1:1 in die Cloud — und wird damit häufig teurer als vorher, weil rund um die Uhr Kapazität bezahlt wird, die on-premises bereits abgeschrieben war.
Regulierte Branchen: Souveränität als Rahmenbedingung
Für Banken, Versicherungen und kritische Infrastruktur stoßen klassische Public-Cloud-Setups schnell an harte rechtliche, regulatorische und datenschutzrechtliche Grenzen (etwa BaFin-Vorgaben und DSGVO). Gangbare Antworten sind hybride Architekturen und Private-Cloud-Umgebungen in deutschen oder europäischen Rechenzentren sowie Architekturen, die mit Sovereign-Cloud-Initiativen wie Gaia-X kompatibel sind. Die Wahl des Anbieters — ob AWS, Azure oder ein europäischer Hoster — sollte dabei herstellerneutral nach den wirtschaftlichen und regulatorischen Kriterien des konkreten Anwendungsfalls erfolgen, nicht nach Anbieter-Roadmaps.
Cloud-Migration in der Praxis: wann sie sich nicht lohnt
Nicht jede Anwendung gehört in die Cloud — eine ehrliche Bestandsaufnahme je Anwendung steht deshalb vor jeder Strategie:
- Stabile, vorhersagbare Last: Läuft ein System gleichmäßig auf vorhandener Hardware, ist der Eigenbetrieb oft günstiger — Elastizität nützt nur bei schwankender Last.
- Nahe Ablösung: Für Systeme, die ohnehin bald abgeschaltet oder ersetzt werden, lohnt der Migrationsaufwand nicht mehr.
- Daten- und Latenzanforderungen: Hohe Datentransferkosten oder harte Latenzvorgaben können gegen die Cloud sprechen.
- Migration ohne Zielbild: Wer nur den Standort wechselt, ohne Architektur und Betrieb anzupassen, bezahlt denselben Zustand teurer.
Auch die Rückführung einzelner Workloads aus der Cloud (Repatriation) kommt in der Praxis vor — sie ist kein Scheitern, sondern Teil einer laufenden Portfolio-Steuerung.