Post-Migration: Warum die Arbeit nach Go-Live erst anfängt

Der Cutover ist vollzogen. Die Applikationen laufen auf AWS. Das Projektteam feiert den erfolgreichen Go-Live. Und dann — nach wenigen Wochen — realisiert das Unternehmen, dass die Migration zwar technisch abgeschlossen ist, aber der versprochene Nutzen noch aussteht. Cloud-Kosten steigen statt zu sinken. Teams arbeiten noch wie im RZ-Betrieb. Niemand hat Kostenverantwortung. Der Well-Architected Review liegt in der Schublade.

Dieses Szenario ist kein Einzelfall. Es ist das häufigste Post-Migration-Muster — und es ist vermeidbar. Post-Migration im Road.MAP-Kontext ist keine Abwicklungsphase, sondern der Beginn einer neuen Betriebsdisziplin.

Die vier kritischen Post-Migration-Bereiche

Road.MAP strukturiert die Zeit nach dem letzten Go-Live in vier Bereiche, die parallel aufgebaut werden müssen:

1. Hypercare: Intensive Betreuung der frisch migrierten Workloads in den ersten Wochen.
2. FinOps-Aktivierung: Kostentransparenz, Budgets und Optimierungsmaßnahmen ab Tag 1.
3. Well-Architected Review: Strukturierte Überprüfung der migrierten Architektur gegen AWS-Best-Practices.
4. Cloud Operating Model: Dauerhafte Betriebsorganisation mit klaren Rollen und Prozessen.

Hypercare: Die ersten vier Wochen nach Go-Live

Die Hypercare-Phase ist das Sicherheitsnetz nach dem Cutover. In Road.MAP-Projekten ist sie kein optionaler Service, sondern ein festes Deliverable jeder Migrationswelle.

Was Hypercare beinhaltet

Erhöhtes Monitoring

24/7-Alarmierung auf alle kritischen Metriken — CPU, Memory, Disk I/O, Latenz, Fehlerrate. CloudWatch-Dashboards werden pro Workload vorkonfiguriert übergeben.

Dedicated On-Call-Support

Storm-Reply-Ingenieure mit Kenntnis des jeweiligen Workloads sind per Telefon erreichbar — Reaktionszeit unter 30 Minuten für P1-Incidents.

Proaktives Performance-Monitoring

Täglich wird geprüft, ob Ressourcen unter- oder überprovisioniert sind. Offensichtliche Over-Provisioning-Probleme werden sofort adressiert.

Lessons-Learned-Dokumentation

Jeder Incident, jede Anomalie und jede Abweichung vom erwarteten Betriebsverhalten wird dokumentiert — als Grundlage für den Well-Architected Review und die nächste Wellenmigration.

Nach der Hypercare-Phase übergibt Storm Reply einen strukturierten Betriebsbericht. Dieser enthält alle beobachteten Issues, getroffenen Maßnahmen und offene Empfehlungen.

FinOps ab Tag 1: Kostenkontrolle ist keine Aufgabe für später

Der häufigste Post-Migration-Fehler: FinOps wird als Optimierungsaufgabe für "nach dem Projekt" eingeplant — und landet nie auf der Agenda. Unternehmen, die keine Kostenverantwortung etablieren, sehen ihre AWS-Rechnungen innerhalb von 12 Monaten deutlich über Budget.

Die FinOps-Grundstruktur, die ab Go-Live existieren muss

Element	Was es liefert	AWS-Tool
Tagging-Strategie	Kostenzuordnung auf Team, Applikation, Umgebung	AWS Cost Allocation Tags
Budgets & Alerts	Automatische Warnung bei Kostenabweichungen	AWS Budgets
Kostentransparenz-Dashboard	Wöchentlicher Überblick nach Account, Service, Team	AWS Cost Explorer / CUDOS
Savings-Plan-Strategie	30–40 % Einsparung durch Commitment auf vorhersagbare Workloads	AWS Savings Plans
Rightsizing-Prozess	Regelmäßige Überprüfung und Anpassung der Instanzgrößen	AWS Compute Optimizer

Storm Reply richtet diese FinOps-Grundstruktur im Rahmen der Migrate-Phase ein — nicht als nachgelagerten Schritt, sondern als Teil des Migration-Factory-Setups.

Well-Architected Review: Lücken systematisch schließen

Eine Migration ist selten perfekt. Ressourcen, die unter Zeitdruck migriert wurden, erfüllen oft nicht alle Anforderungen des AWS Well-Architected Framework. Der erste WAFR nach der Migration macht diese Lücken sichtbar und liefert einen priorisierten Maßnahmenkatalog.

Typische Findings nach einer Lift-and-Shift-Migration

• Security: Fehlende IAM-Least-Privilege-Konfiguration, zu offene Security Groups, keine CloudTrail-Auswertung.
• Reliability: Keine Multi-AZ-Konfiguration für kritische Datenbanken, fehlende Auto-Scaling-Gruppen, ungetestete Backup-Recovery.
• Performance: Over-Provisioning aus On-Premises-Gewohnheit, fehlende CDN-Integration, unoptimierte Datenbankkonfiguration.
• Cost Optimization: On-Demand-Pricing für kontinuierlich laufende Workloads, ungenutzte Ressourcen, fehlende Lifecycle-Policies für S3.
• Operational Excellence: Fehlendes Incident-Management, keine Runbooks, manuelle Deployments.

Storm Reply priorisiert WAFR-Findings nach Impact und Aufwand. High-Risk-Items (HRI) werden sofort adressiert; der Rest fließt in einen 90-Tage-Maßnahmenplan ein.

Cloud Operating Model: Betrieb als Disziplin

Der nachhaltigste Hebel nach einer Migration ist die Etablierung eines Cloud Operating Model — der organisatorischen Struktur, die Cloud nicht als Technologieprojekt, sondern als Betriebsmodell versteht.

Die fünf Säulen des Cloud Operating Model

1. Cloud Center of Excellence (CCoE): Zentrales Team, das Standards setzt, Governance sicherstellt und Enablement für andere Teams liefert — ohne Bottleneck zu werden.
2. Team Topologies: Klare Rollenverteilung zwischen Plattform-Teams, Stream-aligned Teams und Enabling-Teams. DevOps-Kultur statt Silos.
3. Self-Service-Plattform: Entwicklerteams können Infrastruktur nach Standards selbst provisionieren — via Service Catalog, CDK oder Backstage-basierter IDP.
4. FinOps-Verantwortung: Kosten sind Teamverantwortung, nicht Zentralaufgabe. Showback oder Chargeback stellen sicher, dass Kosten dort sichtbar sind, wo sie entstehen.
5. Continuous Improvement: Regelmäßige WAFRs, Gamedays, Post-Incident-Reviews und Architektur-Reviews als institutionalisierte Praxis.

Das Post-Migration-Roadmap-Gespräch

Storm Reply empfiehlt 90 Tage nach dem letzten Go-Live ein strukturiertes Review-Gespräch mit dem Kunden. Agenda:

1. Kosten-Ist vs. Business Case — sind wir auf Kurs?
2. WAFR-Maßnahmenplan — was ist erledigt, was steht aus?
3. Operating-Model-Reifegrad — wo braucht das Team Unterstützung?
4. Modernisierungspipeline — welche Workloads sind bereit für Containerisierung, Serverless oder Managed Services?

Dieses Gespräch ist kein Vertriebstermin — es ist eine ehrliche Bestandsaufnahme, die sicherstellt, dass die Migration tatsächlich den versprochenen Wert liefert.

Häufig gestellte Fragen zur Post-Migration

Wie lange dauert die Hypercare-Phase nach einer Cloud-Migration?

Die Hypercare-Phase dauert in Road.MAP-Projekten standardmäßig 4 Wochen pro Migrationswelle. Für besonders kritische Applikationen wird sie auf 6–8 Wochen verlängert. In dieser Zeit ist Storm Reply mit erhöhter Reaktionsbereitschaft verfügbar und eskaliert erkannte Probleme proaktiv.

Wann sollte der erste Well-Architected Review nach einer Migration stattfinden?

Der erste WAFR sollte 3–6 Monate nach Abschluss der letzten Migrationswelle stattfinden — wenn alle Workloads stabil laufen und ausreichend Betriebsdaten vorliegen. Ein zu früher Review zeigt nur vorübergehende Muster; ein zu später lässt Optimierungspotenzial liegen.

Was ist das häufigste Problem nach einer Cloud-Migration?

Unkontrolliert wachsende Cloud-Kosten. Unternehmen, die keine FinOps-Disziplin einführen, sehen ihre AWS-Rechnungen innerhalb von 6–12 Monaten nach Migration deutlich steigen — durch ungetaggte Ressourcen, Over-Provisioning, vergessene Testumgebungen und fehlende Savings-Plan-Commitment-Strategie.

Bietet Storm Reply Managed Services nach einer Migration an?

Ja. Storm Reply bietet als AWS Managed Service Provider (MSP) optionalen Cloud-Betrieb für Kunden an, die keine eigene Cloud-Ops-Kapazität aufbauen wollen. Dieser Service deckt Monitoring, Incident-Management, Patching und kontinuierliche Optimierung ab.