Cutover Risiken erkennen vor dem Go-Live

Ein Go-Live scheitert selten an einem einzelnen technischen Fehler. Kritisch wird es, wenn während des Cutovers mehrere offene Abhängigkeiten gleichzeitig wirksam werden: ein unvollständiger Datenabzug, eine nicht abgestimmte Berechtigung, ein fehlender Fachbereichsentscheid oder eine Schnittstelle, die nur unter Produktivlast auffällt. Cutover Risiken erkennen heißt deshalb, den Übergang nicht als Termin im Projektplan zu behandeln, sondern als steuerbaren Betriebsprozess mit klaren Kriterien, Verantwortlichkeiten und Eskalationswegen.

Gerade bei S/4HANA-Transformationen, Systemkonsolidierungen oder komplexen Integrationen steht viel auf dem Spiel. Der produktive Betrieb muss weiterlaufen, Geschäftsvorfälle müssen nachvollziehbar bleiben und kritische Daten dürfen weder verloren gehen noch falsch verarbeitet werden. Ein belastbarer Cutover trennt dabei nicht zwischen Technik und Organisation. Er verbindet beides.

Warum Risiken im Cutover oft zu spät sichtbar werden

In vielen Projekten beginnt die konkrete Cutover-Planung erst, wenn Testphasen bereits laufen oder der Go-Live-Termin festgelegt ist. Dann werden Aufgaben zwar in einer Liste erfasst, ihre Voraussetzungen und Auswirkungen bleiben jedoch häufig unklar. Das erzeugt einen gefährlichen Eindruck von Kontrolle: Es gibt einen Plan, aber keine belastbare Entscheidungsgrundlage dafür, ob der Plan unter realen Bedingungen funktioniert.

Ein typisches Beispiel ist die Datenmigration. Ein fachlicher Abgleich kann bestätigen, dass Stammdaten vollständig übertragen wurden. Das sagt noch nichts darüber aus, ob offene Belege, Bestände, historische Referenzen oder abhängige Berechtigungen im Zielsystem korrekt verarbeitet werden. Wenn zusätzlich Schnittstellen zeitversetzt laden, können Fehler erst nach der produktiven Freigabe sichtbar werden.

Auch organisatorische Risiken werden unterschätzt. Fachbereiche sind für Abnahmen benannt, verfügen aber nicht immer über verbindliche Kriterien oder ausreichende Zeitfenster. Externe Dienstleister warten auf Freigaben, während das Projektteam parallel Fehler analysiert. Fehlt ein eindeutiges Entscheidungsmodell, werden kritische Punkte in Statusrunden besprochen, aber nicht entschieden.

Cutover Risiken erkennen: auf Abhängigkeiten statt Aufgaben schauen

Ein reiner Aufgabenplan beantwortet die Frage, wer etwas bis wann erledigt. Für die Steuerung eines Go-Lives reicht das nicht. Entscheidend ist zusätzlich, welche Aufgabe von welchem Ergebnis abhängt, welche Systeme betroffen sind und welche Folgen bei einer Verzögerung entstehen.

Dazu gehört zunächst eine vollständige Betrachtung der Prozesskette. Vom letzten fachlichen Stichtag im Altsystem über Datenextraktion, Transformation und Ladeprozesse bis zur Abstimmung, Freigabe und Wiederaufnahme des Betriebs müssen Übergaben sichtbar sein. Besonders kritisch sind Prozessgrenzen zwischen Fachbereich, SAP-Basis, Entwicklung, Integration, Datenmigration, Informationssicherheit und externen Partnern.

Ein Risiko ist nicht allein deshalb relevant, weil es technisch komplex ist. Relevant wird es, wenn Eintrittswahrscheinlichkeit, Schadensausmaß und begrenzte Reaktionszeit zusammenkommen. Eine bekannte Schnittstellenabweichung kann beispielsweise beherrschbar sein, wenn ein manueller Ersatzprozess geprüft ist und ein verantwortlicher Entscheider bereitsteht. Dieselbe Abweichung wird kritisch, wenn sie Rechnungsstellung, Lieferfähigkeit oder regulatorisch relevante Nachweise beeinträchtigt und erst im produktiven Fenster behoben werden kann.

Die kritischen Risikoarten im Cutover

Besondere Aufmerksamkeit verdienen vier Gruppen. Erstens technische Risiken wie nicht getestete Jobs, unklare Systemkopien, fehlende Transportreihenfolgen oder instabile Schnittstellen. Zweitens Datenrisiken, etwa nicht abgestimmte Migrationsobjekte, fehlerhafte Delta-Logiken oder nicht geklärte Datenverantwortung. Drittens betriebliche Risiken: unzureichende Servicebereitschaft, fehlende Monitoring-Regeln oder nicht erprobte Rückfallprozesse. Viertens Steuerungsrisiken, wenn Entscheidungsrechte, Freigabekriterien und Eskalationen nicht verbindlich definiert sind.

Diese Kategorien überschneiden sich in der Praxis. Eine nicht abgestimmte Berechtigung ist zugleich ein technisches, fachliches und betriebliches Risiko. Deshalb sollte das Risikoregister nicht in getrennten Teillisten geführt werden. Es braucht einen gemeinsamen Blick auf die Auswirkung auf den End-to-End-Prozess.

Mit belastbaren Nachweisen statt mit Ampelstatus steuern

Ein grüner Status ist nur dann aussagekräftig, wenn er auf überprüfbaren Nachweisen beruht. Für jedes kritische Cutover-Element sollte erkennbar sein, was konkret geprüft wurde, wer die Prüfung durchgeführt hat, welche Ergebnisse vorliegen und wer die Freigabe verantwortet. Das gilt für Migrationsläufe ebenso wie für Schnittstellentests, Berechtigungskonzepte, Batch-Verarbeitung und fachliche Abstimmungen.

Bewährt hat sich eine Go-/No-Go-Logik mit wenigen, aber verbindlichen Kriterien. Sie sollte nicht allein an der Anzahl offener Defects hängen. Einige Fehler können akzeptabel sein, sofern sie keine kritischen Geschäftsprozesse beeinträchtigen und ein dokumentierter Umgang mit ihnen besteht. Umgekehrt kann ein einzelner ungeklärter Fehler einen No-Go rechtfertigen, wenn etwa Zahlungsverkehr, Produktionsversorgung, Compliance-Nachweise oder Kundenaufträge betroffen sind.

Wichtig ist die Trennung zwischen Restrisiko und ungeklärtem Risiko. Ein Restrisiko wurde bewertet, einem Verantwortlichen zugeordnet und mit einer Gegenmaßnahme oder bewussten Akzeptanz versehen. Ein ungeklärtes Risiko hat dagegen oft keine gesicherte Ursache, keinen belastbaren Lösungsweg oder keine entscheidungsfähige Instanz. Diese Unterscheidung verhindert, dass offene Punkte kurz vor dem Go-Live sprachlich kleingestuft werden.

Rückfall ist eine Betriebsentscheidung, kein Notfallanhang

Ein Rollback-Konzept wird häufig dokumentiert, aber nicht realistisch geprüft. Dabei ist ein Rückfall nur dann nutzbar, wenn Voraussetzungen, Fristen und Datenfolgen konkret beschrieben sind. Kann das Altsystem nach bereits gestarteten Buchungen weiterbetrieben werden? Welche Daten müssen zurückgespielt oder abgegrenzt werden? Wer darf den Rückfall auslösen und bis zu welchem Zeitpunkt?

Nicht jedes Vorhaben benötigt einen vollständigen technischen Rollback. Bei manchen Migrationen ist er nach bestimmten Schritten unverhältnismäßig oder faktisch ausgeschlossen. Dann braucht es einen kontrollierten Forward-Fix-Ansatz: priorisierte Stabilisierungsmaßnahmen, manuelle Ersatzprozesse, verstärkte Betriebsüberwachung und klar geregelte Kommunikation. Entscheidend ist, diese Entscheidung vor dem Cutover transparent zu treffen, nicht erst unter Zeitdruck.

Ein wirksames Vorgehen für die letzten Projektwochen

In der Endphase sollten Projektteams nicht versuchen, jeden offenen Punkt gleich zu behandeln. Sinnvoll ist eine risikobasierte Taktung. Kritische Abhängigkeiten werden täglich oder je nach Cutover-Fenster mehrfach täglich geprüft. Für jede Abhängigkeit werden Status, Nachweis, Entscheidung, nächste Aktion und verantwortliche Person zentral dokumentiert.

Ein Cutover Command Center schafft dafür einen festen Steuerungsrahmen. Es bündelt nicht jede operative Tätigkeit, sondern die Entscheidungen an den relevanten Übergabepunkten. Das Team benötigt aktuelle Informationen aus Migration, Testmanagement, Fachbereichen, Betrieb und Integrationsverantwortung. Kurze Lagebesprechungen sind dabei wirksamer als umfangreiche Präsentationen, sofern Entscheidungen direkt protokolliert und nachverfolgt werden.

Vor dem produktiven Wochenende sollte mindestens ein realistischer Generalprobe-Lauf stattfinden. Er muss nicht jede einzelne Routine erneut abbilden. Er sollte jedoch den zeitkritischen Pfad testen: Sperren und Freigaben, Datenübernahme, technische Prüfungen, fachliche Abstimmung, Betriebsübergabe und die erste produktive Verarbeitung. Besonders wertvoll sind gemessene Laufzeiten. Sie zeigen, ob das geplante Zeitfenster tatsächlich ausreicht oder nur auf Annahmen beruht.

Nach dem Go-Live endet die Cutover-Steuerung nicht mit der Systemfreigabe. Die Hypercare-Phase braucht definierte Kennzahlen und Meldewege. Dazu gehören beispielsweise Fehlerraten in Schnittstellen, Volumen verarbeiteter Belege, Datenabstimmungen, Antwortzeiten kritischer Transaktionen und die Anzahl nicht geplanter manueller Eingriffe. Erst wenn diese Werte über einen vereinbarten Zeitraum stabil sind, ist der Übergang in den Regelbetrieb fachlich belastbar.

Cutover-Steuerung prüfbar aufsetzen

Quteco unterstützt SAP- und Transformationsprojekte mit Quick Checks, Workshops und operativer Projektbegleitung bei der Strukturierung von Cutover-Plänen, Risikoregistern, Testnachweisen und Go-/No-Go-Entscheidungen. Im Mittelpunkt stehen belastbare Daten, klar zugeordnete Verantwortlichkeiten und eine Steuerung, die auch unter engem Zeitfenster handlungsfähig bleibt.

Ein guter Cutover-Plan nimmt dem Go-Live nicht jede Unsicherheit. Er sorgt jedoch dafür, dass Unsicherheit früh sichtbar wird, Entscheidungen nachvollziehbar getroffen werden und der Betrieb nicht von ungeprüften Annahmen abhängt.