Cloud-Migration: Lift & Shift, Refactor

Wenn ein Unternehmen entscheidet, in die Cloud zu gehen, beginnt selten ein grünes Wiesenprojekt. Meistens stehen 20, 50 oder 200 bestehende Anwendungen im eigenen Rechenzentrum, die irgendwie zu migrieren sind. Wie man das angeht, hängt entscheidend von Zeitdruck, Budget und vom Zustand der Anwendungen ab. Die Branche hat sich auf eine standardisierte Klassifikation geeinigt – die 6R-Strategien. Sie reichen von „so schnell wie möglich rüber" bis „neu schreiben, wenn schon Cloud, dann richtig". Wer in die Cloud-Migration einsteigt – und das tut jede:r FISI früher oder später – muss diese sechs Wege kennen und situativ bewerten können.

Die Analogie passt zum Umzug. Wenn du in eine neue Wohnung ziehst, hast du mehrere Optionen. Du kannst alles einpacken und ungeöffnet rüberbringen (Lift & Shift) – schnell, aber im neuen Bad steht eine Kiste mit Wintermänteln. Du kannst vor dem Umzug aussortieren (Refactor) – mehr Aufwand, dafür ist alles am neuen Ort sinnvoll arrangiert. Du kannst die alten Möbel verkaufen und neue kaufen (Replace) – noch mehr Investition, aber alles ist auf den neuen Raum zugeschnitten. Und manchmal stellst du fest: diesen Schrank brauche ich gar nicht mehr (Retire) – mit oder ohne Umzug. Genau diese Bandbreite findet sich bei Cloud-Migrationen wieder.

1) Die 6 R-Strategien – klick durch

Gartner und AWS haben gemeinsam das 6R-Framework etabliert. Jeder Buchstabe steht für eine Migrations-Strategie mit eigenem Aufwand-Nutzen-Profil:

2) Rehost – die schnelle Lösung im Detail

„Lift & Shift" klingt simpel und ist es technisch tatsächlich – aber es gibt Stolperfallen. Die Idee: Eine bestehende VM aus dem eigenen Rechenzentrum (oder von einem VMware-Cluster) wird in die Cloud kopiert, dort gestartet, Netzwerk umkonfiguriert, fertig. Konkrete Schritte:

1. Discovery: Welche VMs gibt es? Wie groß? Welche Abhängigkeiten zu anderen Systemen? Tools wie AWS Application Discovery Service oder Azure Migrate scannen das Netzwerk und liefern eine Liste.
2. Sizing: Cloud-VM-Größe wählen. Wichtig: nicht 1:1 die Größe der alten Hardware übernehmen – oft waren on-prem-Server überdimensioniert. Stattdessen reale Auslastung der letzten Monate analysieren und passende Cloud-Größe wählen (Right-Sizing).
3. Replikation: Daten und Festplatten der alten VM werden kontinuierlich in die Cloud synchronisiert. Eine Disk-Image-Kopie oder block-level-Replikation läuft Tage oder Wochen im Hintergrund.
4. Cutover: Zum Stichtag wird die alte VM gestoppt, die letzten Änderungen synchronisiert, die Cloud-VM gestartet, DNS umgeleitet. Typische Downtime: 15 Minuten bis wenige Stunden.
5. Validierung: Funktionstests, Performance prüfen, Monitoring sicherstellen.

Ein häufiger Anfängerfehler: Die alte VM ist x86_64, die Cloud-Region bietet günstigere ARM-Instanzen (Graviton bei AWS) – aber die Software läuft nicht auf ARM. Vor dem Rehost prüfen, was die Software an Plattform braucht. Eine andere Falle: Lizenzen, die an spezifische Hardware-MACs gebunden sind, brechen beim Verschieben.

3) Replatform und Refactor – wenn schon, dann richtig

Während Rehost die Anwendung als „Black Box" rüberzieht, modernisieren Replatform und Refactor sie schrittweise. Konkret heißt das oft:

Refactor ist die teuerste, aber wirtschaftlich oft sinnvollste Strategie für strategische Anwendungen. Ein klassisches Beispiel: Ein Monolith, der nur als Ganzes deployt werden kann, wird in mehrere Microservices aufgeteilt. Jeder Service skaliert unabhängig, deployt unabhängig, kann eigene Datenbank haben. Das ermöglicht echte CI/CD-Pipelines mit kontinuierlichen Releases statt der vierteljährlichen Big-Bang-Deployments früher.

4) Migrations-Wellen planen

Niemand migriert 200 Anwendungen am selben Wochenende. Stattdessen plant man Migration Waves – Gruppen von Anwendungen, die zusammen migriert werden. Was zusammen migriert wird, hängt von Abhängigkeiten ab: Eine Anwendung, die ständig mit der Datenbank spricht, muss in derselben Welle wie die Datenbank rüber – sonst hat man bei der Migration extreme Latenz (Cross-Cloud-Hops).

5) Die häufigsten Migrationsfallen

Cloud-Migrationen sind aufwändig, riskant und oft teurer als geplant. Die typischen Fehler tauchen in jedem Projekt wieder auf:

• Lift & Shift „und fertig": Anwendungen werden migriert, aber nie modernisiert. Resultat: Man zahlt Cloud-Preise für eine schlecht ausgelastete VM-Welt – oft teurer als das alte Rechenzentrum. Lift & Shift sollte immer ein Zwischenschritt sein.
• Netzwerk-Architektur vergessen: Wer 50 VMs migriert, ohne VPCs, Subnetting und VPN-Anbindung sauber zu planen, baut sich Spaghetti-Netzwerke, die später kaum noch zu entwirren sind.
• Egress-Kosten unterschätzt: Die Migration selbst erzeugt riesigen ausgehenden Traffic. Tools wie AWS Snowball (versendete Festplatten) oder Azure Data Box können Petabytes physisch transferieren – billiger als per Leitung.
• Identity nicht zentral: Jede VM eigene lokale Benutzer? Katastrophe. Vor der Migration zentrales Identity-Management (Entra ID, AWS IAM Identity Center) etablieren.
• Backups vergessen: „Cloud macht doch Backups" – nein, tut sie nicht automatisch. Backup-Strategie separat planen.
• Mitarbeiter nicht mitgenommen: Wenn Admins Cloud-Konsolen, IaC und CLIs erst lernen müssen, kommt es zu Fehlkonfigurationen. Schulungen sind Teil der Migrationskosten.

6) Migrations-Werkzeuge der Anbieter

Jeder Hyperscaler hat eigene Tools, um Migrationen zu erleichtern. Ein kurzer Überblick über die wichtigsten:

Daneben gibt es Drittanbieter-Tools wie Carbonite Migrate, CloudEndure (heute AWS), oder Open-Source-Werkzeuge wie OpenVPN/rsync für einfache Fälle. Wichtig: Tool-Auswahl sollte Teil der Migrationsstrategie sein, nicht ad hoc entstehen.

7) Geschäftskontext – warum überhaupt migrieren?

Bei aller Technik darf man die Geschäftsmotivation nicht vergessen. Typische Gründe für Cloud-Migration:

• Rechenzentrum-Verträge auslaufen: Statt zu verlängern wird in die Cloud migriert. Häufigster Auslöser.
• Modernisierung bestehender Anwendungen: Refactor öffnet Wege für CI/CD, schnellere Releases, bessere Skalierung.
• Fusionen und Übernahmen: Zwei IT-Welten zusammenführen ist in der Cloud oft einfacher als on-prem.
• Globale Präsenz: Schnell in neuen Regionen verfügbar sein – cloud-typisch eine Frage von Stunden statt Monaten.
• Compliance: Neue regulatorische Anforderungen, die in der eigenen IT teuer wären, sind in zertifizierten Cloud-Regionen leichter zu erfüllen.
• OpEx statt CapEx: Bilanztechnischer Vorteil – siehe Cloud-Preismodelle.

Wichtig: Cloud-Migration ist ein Mittel, kein Ziel. Wer migriert, „weil alle in die Cloud gehen", ohne klares Business-Ziel, landet oft im teuren Lift-&-Shift-Limbus. In der IHK-Prüfung wird gern nach der Wirtschaftlichkeit gefragt: TCO-Vergleich on-prem vs. Cloud über mehrere Jahre.

Zusammenfassung

Cloud-Migration folgt den 6R-Strategien: Rehost (Lift & Shift, VM 1:1 rüber), Replatform (kleine Cloud-Anpassungen, z. B. DB als Managed-Service), Repurchase (Eigenbau durch SaaS ersetzen), Refactor (cloud-native umbauen, Microservices, Serverless), Retire (Anwendung abschalten – 10–20 % der Apps trifft das), Retain (vorerst on-prem behalten, z. B. wegen Compliance oder Hardware-Bindung). Typisches Projekt mischt alle sechs. Vorgehen: Discovery → Sizing → Replikation → Cutover → Validierung, in Migration Waves über Monate. Häufige Fallen: stehengebliebenes Lift & Shift, Netzwerk- und Identity-Chaos, unterschätzte Egress-Kosten, fehlende Backups, ungeschulte Mitarbeiter. Anbieter stellen umfangreiche Migration-Tools bereit (AWS Migration Hub, Azure Migrate, GCP Migration Center). Geschäftsmotivation klar formulieren – Cloud-Migration ist Mittel, kein Selbstzweck.

Verwandte Lektionen: Cloud-Modelle · Cloud-Preismodelle · Rollout-Szenarien · und mehrWeitere relevante LektionenCloud-GrundbegriffeCloud-SkalierbarkeitShared Responsibility ModelTCO-AnalyseMicroservices vs. MonolithContainer vs. VMDatenübernahme planenIHK-Aufgaben Cloud