SAP S/4HANA Migration: Test, Cutover & Go-Live – Der kontrollierte Übergang

Der Go-Live ist kein Datum im Kalender – er ist das Ergebnis eines strukturierten, messbaren Qualitätsprozesses.

Testkonzept, Cutover-Plan, Dress Rehearsal und ein gelebter Go/No-Go-Prozess entscheiden darüber, ob der Übergang ruhig oder chaotisch verläuft.

Die movisco Transition Strategie behandelt Test, Cutover und Go-Live als einen zusammenhängenden, steuerbaren Prozess – nicht als drei separate Ereignisse.

• Vollständiges Testkonzept: Unit, Integration, E2E, UAT, Performance, Security – mit Steuerung in SAP Cloud ALM
• Testautomatisierung mit Tricentis/CBTA: Regressionsabdeckung und Release-Beschleunigung
• Defect Management: Kritikalitätsklassen, Abbruchkriterien und Eskalationslogik
• Cutover-Plan: Minutengenaues Ablaufskript, Downtime-Fenster, Go/No-Go-Kriterien
• Dress Rehearsal: Vollständige Probe unter realen Bedingungen
• Hyper-Care-Konzept: Erste Wochen nach Go-Live abgesichert
• Checkliste (15 Punkte) und KPIs als Qualitätsgate zum Go-Live

Im nächsten Teil der movisco Transition Strategie rückt die kritischste Phase des gesamten Projekts in den Fokus: Test, Cutover und Go-Live. Wir zeigen, wie ein strukturiertes Testkonzept (Unit, Integration, E2E, UAT, Performance) mit SAP Cloud ALM gesteuert wird, wie der Cutover-Plan mit realistischen Downtime-Fenstern und Fallback-Kriterien aufgebaut ist und was einen kontrollierten, ruhigen Go-Live von einem chaotischen unterscheidet.

Rückbezug zu Teil 4: Die Transport-Baseline ist eingefroren. Ab diesem Moment gilt: Kein neuer fachlicher Scope. Neue Anforderungen gehen in den Post-Go-Live-Backlog.

Jede Ausnahme (Urgent Fix) durchläuft das Architecture Board und wird dokumentiert.

• Definition of Done je Testfall: Testfall hat erwartetes Ergebnis, Testdaten, Verantwortlichen und Abnahmekriterium – kein Testfall ohne DoD
• Keine Abnahme ohne Nachweis: Mündliche "alles ok"-Aussagen gelten nicht; Testprotokoll in Cloud ALM ist Pflicht
• Testdatenstrategie vor Teststart: Synthetische Testdaten für DEV; anonymisierter PRD-Refresh für QAS; produktionsnahe Daten für PRE
• Regressionstests nach jedem Bugfix: Jede Korrektur kann neue Fehler einführen; Regressionspaket sichert das ab

Alternative: SAP Solution Manager / Focused Build mit CBTA (Component-Based Test Automation) für Projekte, die noch nicht auf Cloud ALM migriert sind.

Beide Plattformen bieten ChaRM-Integration – der Transportpfad ist in jedem Fall das Rückgrat des Testbetriebs.

Orientierungswert: > 70 % Automatisierungsgrad für Regressionstests vor Go-Live (projektabhängig).

Investition zahlt sich ab dem ersten Release-Zyklus nach Go-Live aus – nicht erst im dritten Jahr. Clean-Core-Hinweis: Automatisierte Regressionstests sind auch langfristig das wichtigste Sicherungsinstrument für Clean-Core-Konformität. Jedes SAP-Release-Upgrade könnte Custom Code tangieren – ein stabiles Regressionspaket erkennt Konflikte, bevor sie in Produktion gehen.

• No-Go: Mindestens 1 offener Blocker (P1) zum geplanten Go-Live-Zeitpunkt
• No-Go: Mehr als 3 offene Critical-Defekte (P2) ohne akzeptierten Workaround
• No-Go: Mock-3-Fehlerquote Datenmigration > 1 %
• No-Go: Dress Rehearsal nicht abgeschlossen oder Downtime überschreitet geplantes Fenster um > 30 %
• No-Go: Steering Committee hat Go-Freigabe nicht erteilt

Wichtig: Die Go/No-Go-Entscheidung wird nicht im Sprint-Team getroffen – sie liegt beim Steering Committee. Das Projektteam liefert die Datenbasis (Defect-Dashboard, Testabdeckung, KPIs). Das Steering Committee trifft die Entscheidung. Beide Verantwortlichkeiten müssen klar getrennt sein.

Die Downtime-Dauer hängt vom Migrationsszenario ab. Folgende Faktoren beeinflussen sie maßgeblich:

• Brownfield (SUM/DMO): Standard-DMO: mehrere Stunden bis > 1 Tag je nach Datenmenge. nZDM reduziert auf Stunden durch Pre-Processing. ZDO nahe Null – aber hoher Vorbereitungsaufwand
• Greenfield / SDT: Primär durch Datenmigrationslaufzeit bestimmt; Mock-3-Laufzeit ist der verlässlichste Schätzer
• Technische Optimierungen: Parallelisierung von Migrations-Jobs, Batch-Processing, Vorab-Archivierung alter Daten (ILM), saubere Netzwerkleitungen zwischen Quell- und Zielsystem

Praxisregel: Plane das Cutover-Fenster 30 % länger als die im Dress Rehearsal gemessene Laufzeit. Der Puffer ist keine Schwäche – er ist Professionalität. Alle Beteiligten kennen das Fenster im Voraus.

Ein Go-Live ohne dokumentierten Fallback-Plan ist ein Go-Live ohne Sicherheitsnetz. Der Fallback-Plan definiert:

1. Bis wann kann noch abgebrochen werden (Point of no Return)
2. Was passiert mit dem Altsystem: War es als Fallback-System eingefroren? Sind alle Stammdaten aktuell?
3. Wer trifft die Abbruchentscheidung (Steering Committee – nicht Projektteam)
4. Wie werden User informiert (vorgefertigte Kommunikationsvorlage, kein Ad-hoc-Text)
5. Wie lange ist der Fallback technisch stabil: ILM, Archivierungsregeln, Berechtigungen

Entscheidungsregel: Wenn der Dress Rehearsal scheitert oder das Zeitfenster deutlich überschreitet, wird der Go-Live-Termin verschoben – nicht das Zeitfenster verlängert. Ein scheiternder Dress Rehearsal ist kein Projektversagen. Er ist genau das, wofür er gedacht ist: Fehler vor dem echten Go-Live sichtbar machen.

Vor der offiziellen Freigabe wird ein definierter Rauchtest-Katalog durchlaufen – nicht der vollständige Testplan, sondern die 10–15 kritischsten Geschäftsprozesse:

• Debitor anlegen / anzeigen (MDG-Validierung)
• Kundenauftrag anlegen und buchen (O2C-Einstieg)
• Eingangsrechnung buchen und Zahlung vorschlagen (P2P)
• Periodenabgrenzung und Sachkontenbuchung (FI/CO)
• Schnittstellenkommunikation zu kritischem Umsystem geprüft
• SoD-kritische Rollen verifiziert (kein unbefugter Zugriff)
• Output-Formulare validiert: kritische Druckdokumente (Rechnung, Lieferschein, Adobe Forms) auf korrekten Inhalt und Ausgabekanal geprüft
• EDI-Subsystem geprüft: Eingangs- und Ausgangs-EDI-Nachrichten (ORDERS, INVOIC) fehlerfrei verarbeitet; kein Fehler im IDoc-Monitor

Keine Go-Live-Freigabe ohne abgeschlossenen Rauchtest mit Protokoll.

Rauchtest-Verantwortliche sind Process Owner, nicht Entwickler – die fachliche Perspektive entscheidet.

• Datenqualität im Produktivsystem: Trotz MDG-Governance tauchen Datenprobleme im produktiven Betrieb auf, die im Test nicht sichtbar waren – schnelle MDG-Korrekturen und Governance-Anpassung
• Performance-Engpässe unter Last: Lasttest deckt nicht immer alle Nutzungsmuster ab; SQL Monitor / SAT helfen bei Analyse; Index-Anpassungen oft kurzfristig möglich
• Berechtigungslücken: User haben keinen Zugriff auf benötigte Fiori-Apps; GRC-Analyse und schnelle Rollenanpassung; kein direkter Produktiv-Zugriff ohne Fallback-Test
• Schnittstellen-Fehler: Inbound/Outbound-Fehler im echten Produktivbetrieb durch unerwartete Payloads; CPI-Fehlerlog und schnelle iFlow-Korrekturen

Der Übergang von der Test- in die Produktivphase ist für Anwender der sichtbarste und emotionalste Moment der gesamten Migration. Kommunikation und Vorbereitung entscheiden hier über Akzeptanz oder Widerstand.

• Go-Live-Kommunikation: Kein Go-Live ohne vorgefertigte Kommunikationspakete: E-Mail an alle User, FAQ-Dokument, Kontakt für Support (Hotline / Ticket-System)
• Schulung vor Go-Live: Enduser-Schulungen finden in den letzten 2 Wochen vor Go-Live statt – zu früh bedeutet Vergessen, zu spät bedeutet Überlastung
• Superuser als erste Eskalationsstufe: Superuser-Netzwerk aus Teil 4 ist jetzt im Einsatz; pro Fachbereich eine Ansprechperson, täglich im Command Center
• Lessons Learned in Hyper-Care: Nach zwei Wochen: Was haben wir nicht vorhergesehen? Was lief besser als erwartet? Diese Erkenntnisse fließen direkt in Teil 6 (Stabilisierung) ein

Projektmuster: Alle 800 Testfälle im UAT-Plan haben die gleiche Priorität. Key User testen, was sie kennen – nicht, was kritisch ist. Kritische Prozesse werden spät oder gar nicht getestet. Folge: Go-Live mit ungetesteten Kernprozessen. Erste Woche produziert P1-Defekte, die im UAT hätten auffallen müssen. Gegenmaßnahme: Testfälle in Cloud ALM nach Prozess-Kritikalität priorisiert. Top-20-Testfälle (kritischste Prozesse) werden dreifach getestet: von verschiedenen Key Usern, mit verschiedenen Datensätzen.

Projektmuster: Die Go/No-Go-Entscheidung wird "aus dem Bauch" getroffen. Niemand hat vorab definiert, was einen Stopp auslöst. Das Steering Committee diskutiert ad hoc. Folge: Politische Entscheidungen statt fachlicher. Projektverzögerung durch endlose Diskussion. Oder: Go trotz P1-Defekten wegen Termindruck. Gegenmaßnahme: Go/No-Go-Kriterien sind im Blueprint definiert (Teil 3), in Teil 4 verfeinert und jetzt verbindlich. Die Entscheidung dauert maximal 30 Minuten – weil die Datenbasis klar ist.

Projektmuster: Der Dress Rehearsal findet mit vereinfachten Daten, verkleinertem Team und ohne echtes Zeitfenster statt. Er gilt als "bestanden", obwohl er kein realistisches Bild liefert. Folge: Überraschungen im echten Cutover: Laufzeit doppelt so lang wie erwartet, Fallback-Aktivierung nicht geübt, Beteiligte kennen ihre Rolle nicht. Gegenmassnahme: Dress Rehearsal hat eigene Go/No-Go-Kriterien. Scheitert er, wird der Go-Live-Termin verschoben. Keine Ausnahmen.

Projektmuster: Nach dem Go-Live löst sich das Projektteam sofort auf. "Läuft doch" ist die Botschaft. Support-Tickets landen beim normalen IT-Helpdesk ohne S/4HANA-Kompetenz. Folge: P1-Defekte werden nicht schnell genug gelöst. User verlieren Vertrauen. Eskalation an Geschäftsführung. Nachträglicher Aufbau eines Command Centers unter Zeitdruck. Gegenmassnahme: Hyper-Care ist Teil des Projektplans, budgetiert und personell besetzt. Dauer: mindestens 2 Wochen. Formelle Abnahme durch Fachbereich, bevor das Projektteam aufgelöst wird.

Projektmuster: User kommen am Montagmorgen ins Büro und erhalten eine kurze E-Mail: "S/4HANA ist jetzt live". Keine FAQ, kein Ansprechpartner, keine Erklärung, was sich geändert hat. Folge: Support-Hotline kollabiert. User sind frustriert. Erste Berichte über "schlechtes System" kursieren. Negative Stimmung prägt die ersten Wochen und schadet der Akzeptanz langfristig. Gegenmassnahme: Kommunikationspaket (E-Mail, FAQ, Kurzanleitung, Superuser-Kontakt) liegt zwei Wochen vor Go-Live fertig vor. Wird erst am Go-Live-Morgen gesendet – nach Freigabe durch das Steering Committee.

Tipp: Das Go/No-Go-Meeting findet auf Basis dieser Checkliste statt – nicht länger als 45 Minuten. Alle offenen Punkte sind entweder akzeptiertes Risiko (dokumentiert) oder No-Go. Kein Graubereich ohne Entscheidung.

Der letzte Teil der movisco Transition Strategie befasst sich mit dem Leben nach dem Go-Live: Wie wird aus einem neuen System ein stabil betriebenes und kontinuierlich weiterentwickeltes Produktivsystem? Wir zeigen, wie Hyper-Care in stabilen Betrieb überführt wird, wie Release-Zyklen und Clean-Core-Prinzipien dauerhaft gelebt werden, und wie BTP-Innovationen gezielt gehoben werden, ohne die Updatefähigkeit zu gefährden.