Was ist Cloud-Migration?

Was ist Cloud-Migration?

Cloud-Migration ist der Prozess des Verschiebens von Anwendungen, Daten oder Workloads von einer Computing-Umgebung in eine andere — am häufigsten von On-Premise-Rechenzentren zu einem Public-Cloud-Anbieter (AWS, Azure, GCP), aber zunehmend sind Cloud-zu-Cloud ("Migration der zweiten Generation") und Cloud-zu-On-Prem ("Repatriierung") auch echte Kategorien. Cloud-Migration ist die größte Infrastruktur-Kategorie in Enterprise-IT-Ausgaben — Gartner prognostiziert globale Public-Cloud-Ausgaben von 700 Mrd. $+ für 2026 — und bleibt eine der riskantesten, teuersten Engineering-Bemühungen, die die meisten Organisationen unternehmen.

Die Entscheidung zu migrieren wird selten rein von Technologie getrieben. Kosten, Agilität, regulatorische Positionierung, Talent-Bindung, Vendor-Konsolidierung und Exit-aus-alterndem-Rechenzentrum-Bedenken spielen alle mit. Die gute Nachricht: das Playbook für Cloud-Migration ist jetzt reif. Die schlechte: die meisten Organisationen unterschätzen weiterhin die Test- und Post-Migrations-Optimierungs-Phasen und enden mit Cloud-Rechnungen 2-3× höher als prognostiziert für die ersten 12-18 Monate.

Die 6 Rs der Cloud-Migration (AWS-Framework)

Die Standard-Taxonomie von AWS, branchenweit genutzt:

1. Rehost ("Lift and Shift") — Workloads as-is zu Cloud-VMs verschieben. Schnellste, billigste Ausführung. Erfasst wenig Cloud-Wert über den CapEx → OpEx-Tausch hinaus.
2. Replatform ("Lift, Tinker, and Shift") — kleinere Optimierungen während der Migration (z.B. selbst-gemanagte PostgreSQL → RDS PostgreSQL). Häufiger Mittelweg.
3. Repurchase (SaaS-Swap) — selbst-gehostete Apps durch SaaS ersetzen (Exchange → Microsoft 365, On-Prem-CRM → Salesforce).
4. Refactor / Re-Architect — für Cloud-native umschreiben (Monolith → Microservices, VMs → Container/Serverless). Höchster Cloud-Wert; höchste Kosten + Risiko.
5. Retire — den Workload komplett abschalten. ~10% der inventarisierten Apps in den meisten Assessments sind ungenutzt.
6. Retain — On-Prem belassen (Compliance, latenz-empfindliche Workloads, kürzlich gekaufte Hardware).

Die Phasen einer echten Migration

1. Discovery + Assessment

Alles inventarisieren — Apps, Abhängigkeiten, Datenflüsse, Netzwerk-Anforderungen, Lizenz-Bedingungen. Tools: AWS Application Discovery Service, Azure Migrate, GCP Migrate Center, Drittanbieter (CloudPhysics, Tanzu CloudHealth). Output: ein Wave-Plan, der Apps nach Migrations-Reihenfolge gruppiert.

2. Pilot-Welle (5-10 Apps)

Nicht-kritische Apps zuerst migrieren, um die Muskel-Memory des Teams aufzubauen und die Landing-Zone-Konfiguration (VPC, IAM, Networking, Monitoring) zu validieren. Lektionen hier propagieren zu späteren Wellen.

3. Produktions-Migrations-Wellen

Nach App-Kritikalität, Abhängigkeiten und Downtime-Toleranz sequenziert. Jede Welle hat ihren eigenen Cutover-Plan: Daten-Sync-Methode, DNS-Strategie, Rollback-Plan, Comm-Plan, Monitoring.

4. Optimierung (Post-Migration)

Die Phase, die die meisten Organisationen überspringen und bereuen. Right-size Instanzen, Kapazität reservieren, Idle-Ressourcen eliminieren, für Cloud-native Services refactoren, Datenübertragungs-Kosten optimieren. Die meiste Cloud-Überausgabe passiert hier — Workloads laufen weiterhin auf der Lift-and-Shift-Größe, weil niemand Post-Migrations-Optimierung besitzt.

Häufige Cloud-Migrations-Fallen

• Alles Lift-and-Shift. Billig auszuführen, teuer zu betreiben. Ohne Optimierung kosten Cloud-Kosten ~2× On-Prem-TCO für äquivalente Compute.
• Daten-Egress ignorieren. Cross-AZ + Cross-Region + Cloud-zu-Internet-Transfers summieren sich schnell. Architektiere Daten-Platzierung, um Egress zu minimieren.
• Nicht unter Last testen. Cloud-Networking, Storage und IAM verhalten sich anders als On-Prem. Apps, die On-Prem gut funktionierten, fallen oft unter Produktions-Last-Patterns in der Cloud aus.
• Identity-Migration unterschätzen. AD → Azure AD, On-Prem-LDAP → Cognito/Okta ist eine der härtesten Abhängigkeiten in jeder Migration.
• Die Kosten-Guardrails überspringen. Tags, Budgets, Alarme, IAM-Policies, die 10k $ EC2-Instanzen verhindern. Diese zu fehlen = Überraschungs-30k $-Rechnungen im Monat 1.
• Migration als One-and-Done behandeln. Cloud entwickelt sich kontinuierlich — deine Architektur braucht kontinuierliche Aufmerksamkeit, sonst ossifiziert sie im First-Year-Design.
• Den Rollback-Plan nicht testen. Wenn die Migration schiefgeht, ist Rollback zu On-Prem oft unmöglich, weil die On-Prem-Umgebung dekommissioniert wurde. Teste Rollbacks während der Pilot-Welle.

FAQ: Cloud-Migration

Wie lange dauert eine typische Migration?

Stark variabel. Eine 50-App-SMB-Migration: 6-12 Monate. Eine Enterprise-500-App-Migration: 2-5 Jahre. Greenfield-Cloud-native-Deployments ohne Migration: Wochen bis Monate.

Was ist mit Multi-Cloud?

Häufig als Strategie ("Lock-in vermeiden"), aber operativ komplex. Die meisten Teams enden mit einer primären Cloud + Nische-Nutzung anderer. Echte Portabilität über Clouds hinweg ist teuer zu pflegen.

Sollte ich alles migrieren?

Nein. Manche Workloads (Mainframe, latenz-empfindliches HFT, kürzlich gekaufte On-Prem-Hardware, Daten mit regulatorischen Daten-Residenz-Anforderungen) sollten nicht migriert werden. Das 6Rs-Framework enthält "Retain" aus einem Grund.

Wie budgetiere ich Cloud-Kosten genau?

Nutze die TCO-Rechner des Cloud-Anbieters (AWS Pricing Calculator, Azure TCO Calculator) für initiale Größenbestimmung. Dann füge 30-50% Puffer für das erste Jahr hinzu — die meisten Projekte finden unerwartete Egress-, Support- oder Schulungs-Kosten.

Was ist "Cloud-Repatriierung"?

Workloads von der Cloud zurück zu On-Prem (oder Co-Location) verschieben. Echte Kategorie 2026 — Unternehmen wie 37signals/Basecamp haben öffentlich repatriiert. Häufige Treiber: Kosten, Compliance, vorhersagbare Workload-Patterns, wo Clouds Elastizitäts-Prämie es nicht wert ist.

Sollte ich Lift-and-Shift oder Refactoren?

Hängt von der App ab. Stabile, geschäftskritische App mit vorhersagbarer Last? Lift-and-Shift zuerst, später optimieren. Neues Produkt mit wachsendem Traffic + Bedarf an Cloud-native-Skalierung? Refactor oder Greenfield neu bauen.

Wie LoadFocus zu Cloud-Migrations-Validierung steht

Der am häufigsten übersprungene Schritt in Cloud-Migrationen ist Performance- + Kapazitäts-Validierung pre-Cutover. LoadFocus-Lasttest validiert, dass migrierte Apps erwartete konkurrente Last handhaben, bevor du DNS umstellst — bringt Cloud-spezifische Engpässe (Cross-AZ-Latenz, IAM-Call-Rate-Limits, gedrosselter Storage) im Teststadium ans Licht, nicht beim Cutover. API-Monitoring trackt Pro-Endpoint-Latenz post-Migration, sodass du Regressionen vs. On-Prem-Baseline fängst.