Cloud-Migrationen scheitern selten an der Technologie. Sie scheitern an unvollständiger Discovery, fehlenden Fundamenten und Cutovers, die nie geprobt wurden. Diese Roadmap behandelt, was auf AWS, Azure oder Google Cloud tatsächlich über Erfolg entscheidet: eine ehrliche Anwendung des 7R-Frameworks, eine Landing Zone vor dem ersten Workload, Datenmigrations-Mechanik, die Integrität bewahrt, und ein Kostenmodell, das den Kontakt mit der ersten Rechnung überlebt.

Mit Assessment und Discovery beginnen

Jeder Migrationsplan ist nur so gut wie sein Inventar. Bevor Sie Strategien wählen, katalogisieren Sie Anwendungen, Server, Datenbanken, Lizenzen und — am wichtigsten — die Abhängigkeiten dazwischen. Undokumentierte Abhängigkeiten sind die häufigste Ursache für Überraschungen am Migrationstag: der Batch-Job ohne Owner, die hartkodierte IP-Adresse, der geteilte File-Mount, den drei Teams vergessen haben.

Alle drei großen Anbieter liefern Discovery-Tooling: AWS Application Discovery Service und Migration Evaluator, Azure Migrate, Google Cloud Migration Center. Lassen Sie Agenten oder agentenlose Kollektoren mindestens zwei bis vier Wochen laufen, um echte Auslastung und Netzwerkflüsse zu erfassen, und klassifizieren Sie dann jeden Workload nach Geschäftskritikalität, Compliance-Anforderungen und Data Gravity. Das Ergebnis sollte ein Wellenplan sein: Gruppen von Anwendungen, die gemeinsam umziehen, weil sie miteinander sprechen.

Das 7R-Framework, korrekt definiert

Das Branchen-Standardframework definiert sieben Strategien — und die Definitionen richtig zu treffen ist wichtig, weil jede ein anderes Kosten-, Risiko- und Zeitprofil trägt:

  • Rehost (Lift and Shift): Den Workload unverändert auf Cloud-VMs verschieben. Der schnellste Weg, aber nicht automatisch billig — eine unveränderte Serverflotte zu On-Demand-Preisen kostet oft mehr als die ersetzte Hardware, bis sie right-sized und committed ist.
  • Replatform (Lift, Tinker and Shift): Gezielte Optimierungen während des Umzugs ohne Änderung der Kernarchitektur — etwa ein selbstverwaltetes PostgreSQL gegen Amazon RDS, Azure Database for PostgreSQL oder Cloud SQL tauschen, oder eine App in Container auf einem Managed-Kubernetes-Service bringen. Es bedeutet nicht, die Cloud-Plattform zu wechseln.
  • Refactor (Re-Architect): Die Anwendung cloud-nativ neu gestalten — Managed Services, horizontale Skalierung, event-getriebene Muster. Höchster Aufwand und höchster langfristiger Ertrag; reserviert für Workloads mit explizitem Business Case.
  • Repurchase: Das selbstgehostete System stilllegen und durch ein SaaS-Produkt ersetzen — der klassische CRM-Move.
  • Retire: Abschalten, was niemand nutzt. Discovery findet typischerweise 10–20 % eines Bestands, der schlicht ausgeschaltet werden kann — die günstigste Migration überhaupt.
  • Retain: Workloads bewusst vorerst on-premises behalten — latenzgebundene Systeme, regulatorische Grenzen oder Anwendungen kurz vor dem End-of-Life.
  • Relocate: Auf Hypervisor-Ebene umziehen ohne Re-Architektur — VMware Cloud on AWS, Azure VMware Solution oder Google Cloud VMware Engine. Nützlich, um ein Rechenzentrum mit Deadline zu räumen.

Reale Programme mischen Strategien: aggressiv retiren und repurchasen, den Long Tail rehosten oder relocaten, die Datenbanken replatformen und die Handvoll Systeme refactoren, die das Geschäft differenzieren.

Die Landing Zone vor dem ersten Workload bauen

Eine Landing Zone ist das Multi-Account- (oder Subscription-, oder Projekt-) Fundament, in dem Ihre Workloads landen: föderierte Identität und SSO, eine Hub-and-Spoke- oder Shared-VPC-Netzwerktopologie, zentralisiertes Logging und Audit-Trails sowie Leitplanken als Policy — AWS Service Control Policies, Azure Policy oder GCP Organization Policies. AWS Control Tower, die Landing Zones des Azure Cloud Adoption Framework und Googles Fabric-FAST-Blueprints liefern meinungsstarke Startpunkte; was immer Sie wählen, definieren Sie es ab Tag eins als Infrastructure as Code. In einen flachen, handgebauten Account zu migrieren ist der Weg, auf dem Teams achtzehn Monate später ihre Cloud-Landschaft neu bauen.

Datenmigrations-Mechanik

Bei den Daten wird die Migration ernst. Für Datenbanken ist das Muster auf jeder Cloud gleich: ein initialer Full Load, gefolgt von Change Data Capture (CDC), das das Ziel bis zum Cutover synchron hält. AWS Database Migration Service, Azure Database Migration Service und GCP Database Migration Service implementieren genau das und reduzieren die Downtime auf die Minuten, die das Umbiegen der Connection Strings dauert. Wenn Sie die Datenbank-Engine wechseln, budgetieren Sie die Schema-Konvertierung separat — Tools wie das AWS Schema Conversion Tool automatisieren vieles, aber Stored Procedures und herstellerspezifisches SQL brauchen immer menschliche Review.

Für Datei- und Objektdaten entscheidet einfache Bandbreiten-Mathematik zwischen Online- und Offline-Transfer: 100 TB über eine dedizierte 1-Gbps-Leitung dauern bei Vollauslastung rund zehn Tage. Online-Optionen sind AWS DataSync, Azure Storage Mover und AzCopy sowie der Google Storage Transfer Service; wenn die Rechnung nicht aufgeht, verschicken Sie die Daten per AWS Snowball, Azure Data Box oder Google Transfer Appliance. Egal welcher Weg: mit Checksummen und Zeilenzählungen validieren — Korruption, die nach dem Abschalten der Quelle entdeckt wird, ist unwiederbringlich.

Cutover-Strategien

Planen Sie den Cutover pro Welle, nicht pro Programm. Die drei praktikablen Muster: Big Bang (alles auf einmal — nur für kleine, risikoarme Systeme), Phased Cutover (Komponenten oder Nutzersegmente inkrementell umziehen) und Parallel Run (Alt und Neu laufen nebeneinander, Ergebnisse werden vor dem Umschalten verglichen). In allen Fällen: DNS-TTLs Tage vorher senken, Change Freeze ums Fenster erklären und — nicht verhandelbar — die Rollback-Prozedur schreiben und proben. Ein nie ausgeführter Rollback-Plan ist eine Hypothese, kein Plan.

Kostenmodellierung jenseits des Kalkulators

Naive Kostenmodelle vergleichen On-Demand-Listenpreise mit abgeschriebener Hardware und beweisen, was der Autor beweisen wollte. Ein ehrliches Modell enthält die Dual-Running-Phase, in der beide Umgebungen live sind, Egress und Datentransfer während der Migration, Tooling und Personal sowie die Betriebskosten des verbleibenden Bestands. Committen Sie Reserved Instances oder Savings Plans erst, nachdem Workloads right-sized sind und sich die Nutzung stabilisiert hat — ein Commitment auf einen überdimensionierten Fußabdruck schreibt die Verschwendung für ein bis drei Jahre fest. Sobald Sie live sind, verlagert sich die Arbeit auf kontinuierliche Optimierung; unser Leitfaden zur Cloud-Kostensenkung behandelt diesen Kreislauf im Detail.

Typische Fehlermuster

  • Unbekanntes migrieren: Dependency-Mapping überspringen und Integrationen um 2 Uhr nachts in der Cutover-Nacht entdecken.
  • Keine Landing Zone: Workloads in einem unstrukturierten Account landen lassen und die Re-Fundamentierung später bezahlen.
  • Rehost-Schätzungen für final halten: Lift-and-Shift ist eine Ausgangsposition, kein Dauerzustand; ohne Right-Sizing enttäuscht die Rechnung.
  • Ungetesteter Rollback: Reversibilität annehmen statt sie zu proben.
  • Die Menschen vergessen: Betriebsteams brauchen Cloud-Skills vor dem Go-live, nicht nach dem ersten Incident.
  • Die unsterbliche „temporäre" Umgebung: Dual-Run-Setups, die still ein Jahr lang abrechnen, weil niemand das Decommissioning besaß.

Wo anfangen?

Discovery fahren, jedem Workload eines der sieben R zuweisen, die Landing Zone bauen und zuerst eine risikoarme Welle umziehen, um die Maschinerie Ende-zu-Ende zu testen. Wenn Sie erfahrene Hände am Plan wollen — vom Assessment bis zum Cutover — führt unsere Cloud-Practice Migrationsprogramme auf AWS, Azure und GCP durch, und unser Managed-Services-Team betreibt die Umgebung, sobald Sie angekommen sind.

Ein Umzug steht an? Unsere AWS-Migrationsleistungen bringen Sie in 8–16 Wochen auf ein Well-Architected Fundament — Festpreis, stufenweiser Cutover, Rollback-Plan schriftlich.

Tags: #Cloud #Migration #AWS #Azure #GCP #Strategie