Migration Factory: Große Workload-Portfolios skaliert auf AWS migrieren

Warum Migration Factories jetzt relevant sind

Die erste Phase einer Cloud-Migration — Assessment, Landing Zone, Pilot-Workloads — folgt einem projektbasierten Ansatz. Doch ab dem Moment, in dem 10+ Workloads migriert werden sollen, stößt dieses Modell an seine Grenzen. Jede individuelle Migration erfordert Planung, Testing und Cutover. Ohne Systematisierung wächst der Aufwand linear mit der Anzahl der Workloads.

AWS Prescriptive Guidance identifiziert die Migration Factory als den empfohlenen Ansatz für große Migrationen: 20 bis 50 Prozent eines typischen Enterprise-Portfolios bestehen aus wiederholbaren Mustern, die durch Automatisierung und Standardisierung erheblich beschleunigt werden können (AWS: Strategy for Large-Scale Migrations).

Die Konsequenz: Migrationen, die ohne Factory-Ansatz über ein Jahr dauern, lassen sich mit einer eingespielten Migration Factory in 3 bis 6 Monaten abschließen (AWS: Cloud Migration Factory Solution).

Was ist eine Migration Factory?

Eine Migration Factory überträgt Prinzipien der industriellen Fertigung auf Cloud-Migrationen. Statt jede Migration als Einzelprojekt zu behandeln, werden standardisierte Prozesse, Rollen und Automatisierungen aufgebaut.

Factory-Prinzip

Wie in einer Fertigungsstraße werden wiederkehrende Aufgaben (Discovery, Replikation, Testing, Cutover) standardisiert und automatisiert. Individuelle Anpassungen erfolgen nur, wo es der Workload erfordert.

Wave-basierte Migration

Workloads werden in Gruppen (Waves) eingeteilt und wellenweise migriert. Jede Wave wird vollständig abgeschlossen und validiert, bevor die nächste beginnt.

Kontinuierliche Verbesserung

Lessons Learned aus jeder Wave fließen in die Prozesse der nächsten Wave ein. Die Factory wird mit jeder Iteration schneller und zuverlässiger.

Rollenbasierte Teams

Feste Rollen (Migration Lead, Wave Manager, App Owner, Netzwerk-Engineer, QA) mit klaren Verantwortlichkeiten statt wechselnder Projektteams.

Der Migration-Factory-Prozess in fünf Schritten

Eine Migration Factory arbeitet in einem repetitiven Zyklus. Die folgenden fünf Schritte wiederholen sich für jede Wave:

1. Discovery & Grouping: Workloads werden inventarisiert, Abhängigkeiten erfasst und nach Migrationsmustern gruppiert. Tools: AWS Migration Hub, Application Discovery Service.
2. Wave-Planning: Workloads werden priorisiert und in Waves eingeteilt. Kriterien: Geschäftskritikalität, technische Komplexität, Abhängigkeiten, Downtime-Toleranz.
3. Migration Execution: Workloads werden mit AWS Application Migration Service (MGN) repliziert und in der Zielumgebung bereitgestellt. Paralleler Betrieb während der Replikationsphase.
4. Validation & Testing: Automatisierte und manuelle Tests in der Zielumgebung. Funktionstests, Performance-Tests, Integrationstest mit abhängigen Systemen.
5. Cutover & Decommission: Geplanter Cutover mit definiertem Rollback-Plan. Nach erfolgreicher Validierung: Dekommissionierung der Quellsysteme.

Wave-Planung: Vom Piloten zur Skalierung

Die Wave-Planung ist der kritischste Schritt in der Migration Factory. AWS empfiehlt eine progressive Skalierung (AWS Blog: MGN Best Practices):

Die erste Wave ist bewusst klein gehalten — nicht aus technischen Gründen, sondern um dem Team die Möglichkeit zu geben, Prozesse zu lernen und Fehler in einem kontrollierten Umfeld zu machen. Kritische Anwendungen werden erst in späteren Waves migriert, wenn die Factory eingespielt ist.

AWS-Services für die Migration Factory

Die Migration Factory nutzt ein abgestimmtes Set von AWS-Services:

AWS Application Migration Service (MGN)

Kerntool für Server-Migrationen. Repliziert Workloads kontinuierlich von On-Premises nach AWS. Unterstützt seit 2022 anwendungszentriertes Management mit Waves und Bulk-Operationen (AWS Docs: Migration at Scale).

AWS Migration Hub

Zentrale Konsole zur Nachverfolgung des Migrationsstatus aller Workloads über alle Tools hinweg. Aggregiert Daten aus MGN, DMS und anderen Migrationstools.

Cloud Migration Factory on AWS (Solution)

Open-Source-Orchestrierungslösung von AWS. Automatisiert Wave-Planung, Portfolio-Assessment und koordiniert die Ausführung mit MGN. Wird von AWS Professional Services und Partnern wie Storm Reply für große Migrationen eingesetzt (AWS: Solution Overview).

AWS Database Migration Service (DMS)

Für Datenbank-Migrationen mit kontinuierlicher Replikation und Schema-Konvertierung. Ergänzt MGN für die Datenbankschicht.

AWS Application Discovery Service

Automatisierte Erfassung von Workloads, Abhängigkeiten und Performance-Daten. Grundlage für das Grouping und die Wave-Planung.

Was sich ändert, wenn die Skalierung beginnt

Der Sprung von 10 auf 50+ Workloads pro Wave verändert die Migration qualitativ. Diese Aspekte müssen vorher adressiert sein:

Netzwerk-Kapazität

Die initiale Replikation großer Datenmengen belastet die Bandbreite zwischen On-Premises und AWS. Bei 50+ Servern mit je 500 GB Daten muss die WAN-Verbindung die Last der parallelen Replikation tragen. AWS Direct Connect oder dedizierte VPN-Tunnel sind ab dieser Größenordnung Pflicht.

Cutover-Koordination

Bei kleinen Waves reicht ein einzelnes Cutover-Fenster. Bei 50+ Workloads mit komplexen Abhängigkeiten muss der Cutover über mehrere Wochenenden verteilt oder in Sub-Waves mit getrennten Cutover-Zeitfenstern organisiert werden.

Testing-Automatisierung

Manuelle Validierung skaliert nicht. Ab Wave 3 müssen automatisierte Smoke-Tests, Health-Checks und Integrationstests die manuelle Prüfung weitgehend ersetzen. Infrastructure-as-Code (CloudFormation, CDK) für die Zielumgebung wird zur Voraussetzung.

Kommunikation und Change Management

Ab 50+ Workloads sind dutzende Application Owner betroffen. Klare Kommunikationsprozesse, standardisierte Cutover-Runbooks und ein definierter Eskalationspfad werden unverhandelbar.

Storm Reply Migration-Factory-Ansatz

Storm Reply ist AWS Premier Consulting Partner mit AWS Migration Competency und hat über 600 Cloud-Projekte im DACH-Raum begleitet. Der Storm Reply Migration-Factory-Ansatz kombiniert das AWS-Framework mit eigener Methodik:

• Road.MAP-Integration: Die Migration Factory wird im Rahmen der Storm Reply Road.MAP aufgebaut — mit klarer Priorisierung und Business-Case-Orientierung.
• Runbook-Bibliothek: Über 600 Projekte hinweg aufgebaute Runbooks für wiederkehrende Migrationsmuster (Windows Server, Linux, Datenbanken, Container).
• MAP-Förderung: Die Migration Factory wird typischerweise in der Migrate-Phase des AWS Migration Acceleration Program (MAP) betrieben — mit bis zu 25 % AWS-Service-Credits.
• Managed Services: Nach Abschluss der Migration übernimmt das Storm Reply Managed-Services-Team den laufenden Betrieb.

Praxisbeispiel: Edison — Cloud-Migration in der Energiewirtschaft

Edison, eines der ältesten Energieunternehmen Europas, migrierte mit Storm Reply lokale Geschäftsanwendungen in die AWS Cloud (reply.com).

Ausgangslage: Heterogene On-Premises-Landschaft mit zahlreichen Legacy-Anwendungen, die für unterschiedliche Geschäftsbereiche betrieben wurden.

Ansatz: Schrittweise Migration mit einer industrialisierten Delivery. Storm Reply setzte auf Infrastructure-as-Code (AWS CDK), serverlose Architekturen (Lambda, API Gateway, SNS, SQS) und containerisierte Workloads (Amazon EKS). Netzwerk-Konnektivität über AWS Direct Connect und Transit Gateway.

Ergebnis:

• Verbesserte Sicherheit und Aufgabentrennung zwischen Geschäftsbereichen
• Höhere Ausfallsicherheit durch Multi-AZ-Architektur
• Schnellere Infrastruktur-Bereitstellung durch Automatisierung
• Modernisierung während der Migration — nicht erst danach

Vorteile und Herausforderungen

Vorteile der Migration Factory

• Geschwindigkeit: Wiederholbare Prozesse reduzieren die Zeit pro Workload mit jeder Wave.
• Qualität: Standardisierte Runbooks und automatisierte Tests minimieren menschliche Fehler.
• Kostentransparenz: Der Factory-Ansatz macht Migrationskosten pro Workload planbar und vergleichbar.
• Skalierbarkeit: Die Factory wächst mit dem Portfolio — von 10 auf 500+ Workloads ohne proportionalen Teamausbau.
• MAP-Förderung: Der industrialisierte Ansatz maximiert die Nutzung von AWS-Service-Credits in der Migrate-Phase.

Herausforderungen und Limitierungen

• Initiale Einrichtung: Die Factory selbst benötigt 2-4 Wochen Aufbauzeit, bevor die erste produktive Wave starten kann.
• Nicht alles passt in die Factory: Hochkomplexe Anwendungen mit individuellen Abhängigkeiten erfordern weiterhin maßgeschneiderte Migrationsplanung.
• Organisatorischer Reifegrad: Application Owner müssen bereit sein, in einem strukturierten Prozess mitzuarbeiten. Ohne Change Management stagniert die Factory.
• Netzwerk-Engpässe: Parallele Replikation großer Datenmengen erfordert ausreichende WAN-Bandbreite — häufig der limitierende Faktor.

Häufige Fragen zur Migration Factory

Ab welcher Größe lohnt sich eine Migration Factory?

Als Faustregel: ab 30+ Workloads. Bei kleineren Portfolios ist der Aufwand für den Factory-Aufbau nicht gerechtfertigt — hier reicht ein projektbasierter Ansatz mit Wave-Planung.

Kann ich Rehost und Refactor in derselben Factory mischen?

Ja, aber in getrennten Swim Lanes. Rehost-Workloads (Lift-and-Shift) durchlaufen die Standard-Factory mit MGN. Refactor-Workloads erfordern individuelle Architekturplanung und werden parallel in eigenen Streams bearbeitet.

Was passiert, wenn eine Wave fehlschlägt?

Jede Wave hat einen definierten Rollback-Plan. Scheitert die Validierung, werden die Quellsysteme wieder aktiviert. Die Lessons Learned fließen in die nächste Wave ein. Die Factory-Methodik sieht vor, dass Fehler früh und kontrolliert auftreten — deshalb beginnt Wave 0 mit unkritischen Workloads.

Wie messe ich den Fortschritt einer Migration Factory?

Typische KPIs: Workloads pro Wave, durchschnittliche Cutover-Dauer, Rollback-Rate, Time-to-Value (Zeit bis zur produktiven Nutzung), Kostenreduktion vs. On-Premises.

Ausblick: Migration Factories werden zum Standard

AWS baut die Toolchain für Migration Factories kontinuierlich aus. Die Cloud Migration Factory on AWS Solution ist als Open-Source-Projekt auf GitHub verfügbar und wird aktiv weiterentwickelt (GitHub). MGN unterstützt seit 2022 anwendungszentriertes Management mit Waves — eine direkte Antwort auf die Bedürfnisse von Factory-basierten Migrationen.

Für DACH-Unternehmen, die noch vor großen Migrationsvorhaben stehen, bietet der Factory-Ansatz die realistischste Perspektive, Hunderte von Workloads in einem vertretbaren Zeitrahmen zu migrieren — ohne die Qualität zu opfern.