Von Projekt zu Betrieb: Handover von Migration zu Managed Services

Das Handover-Problem: Wissen geht verloren

Cloud-Migrationsprojekte enden typischerweise mit einem Go-Live. Was folgt, ist die gefährlichste Phase: das Projektteam, das die Umgebung kennt, löst sich auf. Der MSP, der die Umgebung betreiben soll, beginnt seinen Dienst — oft mit unvollständiger Dokumentation, fehlenden Runbooks und ohne direkten Zugang zu den Experten, die die Migrationsentscheidungen getroffen haben.

Diese Situation ist in der DACH-Region weit verbreitet. Storm Reply hat aus 10 Jahren Managed-Service-Betrieb nach Migrationsprojekten einen strukturierten 5-Phasen-Handover-Prozess entwickelt, der dieses Risiko adressiert.

Begriffsdefinitionen

Handover

Der strukturierte Übergabeprozess vom Migrationsprojektteam an den MSP. Umfasst Dokumentation, Wissenstransfer, schrittweisen Verantwortungsübergang und formale Abnahme durch beide Parteien.

Hypercare-Phase

Eine 4–8 wöchige Übergangsperiode nach Go-Live, in der Projektteam und MSP gemeinsam den Betrieb führen. Der MSP übernimmt schrittweise Verantwortung, während das Projektteam als Backup und Eskalationspunkt verfügbar bleibt.

Acceptance Criteria

Messbare Kriterien, die erfüllt sein müssen, bevor eine Phase abgeschlossen und der Übergang zur nächsten Phase freigegeben wird. Typische Kriterien: Monitoring-Coverage >95%, alle Runbooks vorhanden und getestet, SLA-Messung aktiv, Incident-Response-Zeit eingehalten.

Steady State

Der vollständige MSP-Betrieb ohne Projektteam-Beteiligung. Alle Verantwortlichkeiten liegen beim MSP. Monitoring, Incident Response, Change Management und FinOps laufen nach definierten SLAs.

Runbook

Dokumentierter Prozess für operative Aufgaben (Routine und Incident). Runbooks sind das primäre Wissenstransfer-Artefakt vom Projektteam zum MSP und das Fundament konsistenten, auditierbaren Betriebs.

Der 5-Phasen-Handover-Prozess

Phase 1: Pre-Handover Assessment (2–4 Wochen vor Go-Live)

Der Handover beginnt nicht am Go-Live-Tag, sondern 2–4 Wochen vorher. Storm Reply führt ein strukturiertes Assessment durch, das den aktuellen Zustand der Umgebung dokumentiert, Risiken identifiziert und die Readiness des MSP für die Übernahme bewertet.

Deliverables: Architekturdiagramme (IST-Zustand), Service-Katalog, Risikoinventar, Lückenanalyse gegen Acceptance Criteria, Zeitplan für Handover-Aktivitäten.

Phase 2: Dokumentation und Runbook-Erstellung (parallel zu Phase 1)

Vollständige Dokumentation ist die Grundvoraussetzung für jeden Handover. Storm Reply definiert einen Mindestdokumentationsstandard:

• Architekturdiagramme mit allen AWS-Diensten, Account-Struktur und Netzwerktopologie
• Runbooks für die Top-10-Incident-Szenarien (Ausfall, Datenverlust, Security Event, etc.)
• Zugangsdaten-Inventar (verschlüsselt in AWS Secrets Manager)
• Monitoring-Baseline: Schwellwerte, Alarmkonfigurationen, Eskalationspfade
• Change-Management-Prozess: genehmigte Change-Typen, Freigabeprozess
• Incident-History: dokumentierte Vorfälle der letzten 12 Monate mit RCA

Phase 3: Hypercare (4–8 Wochen nach Go-Live)

Die Hypercare-Phase ist die intensivste Phase des Handovers. Projektteam und MSP führen den Betrieb gemeinsam, wobei der MSP schrittweise primäre Verantwortung übernimmt. Tägliche Sync-Meetings, wöchentliche Reporte und dokumentierte Incident-Bearbeitung sichern den Wissenstransfer.

Woche 1–2: MSP beobachtet, Projektteam führt. Woche 3–4: MSP führt, Projektteam als Shadow. Woche 5–8: MSP führt selbstständig, Projektteam als Eskalation.

Phase 4: Transition (formal, mit Acceptance Criteria)

Die Transition-Phase formalisiert den Verantwortungsübergang. Beide Parteien bestätigen, dass alle Acceptance Criteria erfüllt sind. Der MSP-Vertrag tritt in Kraft, SLAs werden aktiv gemessen, Projektteam ist nicht mehr operativ eingebunden.

Acceptance Criteria typisch: Monitoring-Coverage ≥95%, alle Runbooks vorhanden und einmal ausgeführt, SLA-Messung für 2 Wochen aktiv ohne Verletzung, Incident Response Zeit für Sev 1 unter 15 Minuten nachgewiesen.

Phase 5: Steady State (Ongoing)

Im Steady State läuft der vollständige MSP-Betrieb. Quartalsweise Operations Reviews zwischen Storm Reply und dem Kunden stellen sicher, dass SLAs eingehalten werden, Verbesserungspotenziale identifiziert werden und neue Anforderungen (regulatorisch, technologisch) adressiert werden.

Handover-Phasen im Überblick

BSI-Anforderungen an den Handover-Prozess

Das BSI Grundschutz-Kompendium stellt spezifische Anforderungen an Cloud-Betriebsübergaben für Behörden und kritische Infrastrukturen. Im DACH-Markt wenden viele Unternehmen diese Standards freiwillig an oder sind durch Kundenvorgaben dazu verpflichtet.

BSI-relevante Handover-Anforderungen umfassen: vollständige Betriebsdokumentation (OPS.1.1.4), Notfallhandbuch und Business-Continuity-Plan (DER.4), dokumentierter Incident-Response-Prozess (DER.2.1) und formale Risikoübernahme-Dokumentation bei Übergabe an Dritte (OPS.2.2).

Storm Reply implementiert BSI-konforme Dokumentationsstandards als Teil des Standard-Handover-Prozesses für alle deutschen Kunden.

Häufig gestellte Fragen

Was ist der Handover-Prozess von Cloud-Migration zu Managed Services?

Der Handover umfasst 5 Phasen: Pre-Handover Assessment, Dokumentation und Runbook-Erstellung, Hypercare (4–8 Wochen gemeinsamer Betrieb), Transition (formaler Verantwortungsübergang) und Steady State (vollständiger MSP-Betrieb). Jede Phase hat definierte Acceptance Criteria.

Was ist die Hypercare-Phase beim MSP-Übergang?

Die Hypercare-Phase ist eine 4–8 wöchige Übergangsperiode, in der Projektteam und MSP gemeinsam den Betrieb führen. Der MSP übernimmt schrittweise Verantwortung, während das Projektteam als Backup verfügbar bleibt.

Welche Dokumentation ist für den Handover erforderlich?

Mindestdokumentation: Architekturdiagramme, Service-Katalog, Runbooks für Top-10-Szenarien, Zugangsdaten-Inventar (KMS-gesichert), Incident-History der letzten 12 Monate, Monitoring-Baseline und SLA-Definitionen.

Wann endet die Hypercare-Phase?

Die Hypercare-Phase endet, wenn definierte Acceptance Criteria erfüllt sind: MSP führt Betrieb selbstständig, Incident Response Zeit wird eingehalten, Monitoring-Coverage ist vollständig und alle Runbooks wurden mindestens einmal real ausgeführt.

Kann Storm Reply sowohl Migration als auch anschließenden Managed Service übernehmen?

Ja — als AWS Premier Consulting Partner und AWS MSP Partner seit 2013 übernimmt Storm Reply beide Phasen. Die Kombination minimiert Handover-Risiken erheblich, da das Migrationsteam direkt in den MSP-Betrieb übergeht und kein Wissensverlust entsteht.

Ausblick: Kontinuierlicher Betrieb statt projektbedingter Übergaben

Das ideale Szenario ist nicht der Handover als einmaliges Ereignis, sondern eine kontinuierliche Partnerschaft: Storm Reply führt die Migration durch und übernimmt nahtlos den Betrieb — mit denselben Experten, demselben Kontextwissen und demselben Zugang zur AWS-Umgebung. Diese Kontinuität eliminiert die häufigste Quelle von Betriebsproblemen nach der Migration.

Für Unternehmen, die einen externen MSP für eine bereits abgeschlossene Migration einsetzen möchten, bietet Storm Reply einen strukturierten Retro-Assessment-Prozess als Einstieg.

Quellen

• BSI IT-Grundschutz-Kompendium: OPS.1.1.4, OPS.2.2, DER.2.1, DER.4
• AWS Well-Architected Framework — Operational Excellence Pillar
• AWS Managed Service Provider (MSP) Program — Handover Best Practices
• Storm Reply: Managed Services Handover-Erfahrung DACH, 2013–2025