Ein Cutover wird häufig mit dem Go-live gleichgesetzt. Operativ ist er jedoch die kritischste Phase davor und währenddessen: der kontrollierte Wechsel vom alten in das neue System, Netzwerk, ERP, MES oder Betriebsmodell. Auf die Frage „Wie lange dauert Cutover?“ gibt es deshalb keine belastbare Standardantwort. Ein kleiner, sauber abgegrenzter Wechsel kann in wenigen Stunden erfolgen. Bei einer SAP-Integration, einer MES-Einführung im Werk oder einer standortübergreifenden Netzwerkmigration dauert der Cutover inklusive Stabilisierung oft mehrere Tage – und die Vorbereitung mehrere Wochen oder Monate.
Entscheidend ist nicht, wie kurz das Zeitfenster im Projektplan aussieht. Entscheidend ist, ob Daten, Prozesse, technische Abhängigkeiten und Verantwortlichkeiten innerhalb dieses Fensters kontrolliert umgestellt werden können. Ein zu optimistisch geplanter Cutover erzeugt keine Effizienz. Er verlagert Risiko in den Betrieb, in die Produktion und in die Kundenversorgung.
Wie lange dauert ein Cutover realistisch?
Als grobe Orientierung gelten drei Ebenen. Das eigentliche technische Umschalten – etwa die Aktivierung einer neuen Netzwerkumgebung, die Produktivsetzung eines Systems oder der Wechsel von Schnittstellen – dauert häufig zwischen zwei Stunden und einem Wochenende. Bei stark integrierten Unternehmenslandschaften reicht das jedoch nicht aus.
Hinzu kommen die vorbereitenden Aktivitäten: Datenextraktion, Bereinigung, Migrationstests, Berechtigungsprüfung, Deployment-Proben, Kommunikationsplanung und die Freigabe durch Fachbereich, IT und gegebenenfalls Compliance. Diese Phase beansprucht typischerweise vier bis zwölf Wochen. Bei globalen Rollouts, regulierten Umgebungen oder Produktionswerken mit geringer Wartungszeit kann sie deutlich länger dauern.
Nach dem Umschalten beginnt die Hypercare-Phase. Sie dauert meist ein bis vier Wochen. In dieser Zeit werden Incidents priorisiert bearbeitet, Schnittstellen überwacht, Prozessabweichungen bewertet und offene Restpunkte konsequent geschlossen. Wer nur die Nacht des Go-live als Cutover rechnet, unterschätzt den tatsächlichen Aufwand und plant zu wenig Ressourcen ein.
Ein Beispiel aus der Factory IT: Wird ein MES an eine bestehende ERP-, Maschinen- und Qualitätslandschaft angebunden, kann das technische Deployment an einem Wochenende erfolgen. Der Gesamt-Cutover umfasst trotzdem die Sperrung von Stammdatenänderungen, den letzten Datenabzug, die Validierung von Produktionsaufträgen, Tests an der Linie, die Freigabe durch Qualität und die Absicherung des Fallbacks. Hier entscheidet nicht die Installationszeit über die Dauer, sondern die Zeit bis zur sicheren Produktionsfähigkeit.
Die Faktoren, die die Cutover-Dauer bestimmen
Die Dauer hängt vor allem von der Komplexität und Kritikalität der betroffenen Landschaft ab. Vier oder fünf Systeme mit klar dokumentierten Schnittstellen sind etwas anderes als eine über Jahre gewachsene Umgebung mit manuellen Workarounds, lokalen Sonderprozessen und unbekannten Abhängigkeiten.
Besonders relevant sind Datenvolumen und Datenqualität. Müssen nur Konfigurationen und aktuelle Bewegungsdaten übertragen werden, lässt sich ein Cutover meist gut terminieren. Müssen Historien, Dokumente, technische Objekte oder Millionen von Datensätzen migriert und abgestimmt werden, steigen Laufzeit und Validierungsaufwand. Langsame Datenläufe sind dabei nicht das einzige Problem. Kritischer sind fehlerhafte Zuordnungen, Dubletten und Abweichungen zwischen Quell- und Zielsystem.
Auch Integrationen verlängern das Zeitfenster. ERP, MES, Lagerverwaltung, Identity Management, Monitoring, OT-Systeme oder Partner-Schnittstellen müssen zum Stichtag in der richtigen Reihenfolge verfügbar sein. Ein einzelnes fehlendes Zertifikat, eine nicht aktualisierte Firewall-Regel oder eine unklare Verantwortlichkeit kann den geplanten Übergang stoppen.
In Infrastrukturprojekten gilt dasselbe Prinzip. Bei einer LAN-/WAN- oder NAC-Migration ist nicht die Anzahl der Switches allein ausschlaggebend. Entscheidend sind Abhängigkeiten zu Produktionsanlagen, VoIP, WLAN, Druckern, Zutrittslösungen, zentralen Security-Komponenten und lokalen Betriebszeiten. Ein Werk mit 24/7-Produktion hat ein anderes Cutover-Modell als ein Bürostandort mit einem Wartungsfenster am Wochenende.
Schließlich bestimmen Governance und Entscheidungsfähigkeit die Dauer. Wenn die Freigabe für einen Rollback, eine Ausnahme oder einen zusätzlichen Test erst über mehrere Hierarchiestufen eingeholt werden muss, verliert das Projekt im kritischen Zeitfenster wertvolle Minuten. Ein Cutover braucht daher klar benannte Entscheidungsbefugnisse – nicht nur ein umfangreiches Statusdeck.
Cutover-Zeitfenster richtig planen
Ein belastbarer Plan trennt zwischen Vorbereitung, technischem Umschalten, fachlicher Validierung und Stabilisierung. Diese Phasen dürfen nicht zu einem einzigen Balken mit der Bezeichnung „Go-live-Wochenende“ zusammengezogen werden. Nur die Trennung macht sichtbar, welche Teams wann verfügbar sein müssen und wo echte Risiken liegen.
Die technische Reihenfolge muss auf einem getesteten Runbook basieren. Darin steht nicht nur, was getan wird, sondern auch wer die Aufgabe ausführt, wie der Nachweis aussieht, bis wann die Aufgabe abgeschlossen sein muss und welche Folgeaktivität davon abhängt. Formulierungen wie „Daten migrieren“ oder „Schnittstellen prüfen“ reichen nicht aus. Erforderlich sind konkrete Kriterien: Welche Datenmenge wird erwartet? Welche Kontrollsummen müssen übereinstimmen? Welche Testtransaktionen bestätigen die Betriebsfähigkeit?
Für komplexe Vorhaben ist ein Probecutover unverzichtbar. Er liefert die realistischste Antwort auf die Frage, wie lange ein Cutover dauert. Das Team misst Laufzeiten unter möglichst produktionsnahen Bedingungen, erkennt Engpässe und kann die Reihenfolge anpassen. Ein Dry Run deckt oft auf, dass nicht die Migration selbst, sondern Freigaben, manuelle Validierungen oder nicht erreichbare Ansprechpartner den Ablauf verlängern.
Ein guter Cutover-Plan enthält außerdem ausreichend Reserve. Diese Reserve ist kein Zeichen schlechter Planung. Sie ist die kontrollierte Absicherung gegen erwartbare Abweichungen: ein Datenjob läuft länger, ein Testfall muss wiederholt werden oder eine Fachabteilung benötigt zusätzliche Prüfung. Ohne Puffer werden kleine Verzögerungen sofort zu Management-Eskalationen.
Go/No-Go und Rollback: Die zwei Entscheidungen, die zählen
Ein Cutover ist erst steuerbar, wenn Go/No-Go-Kriterien messbar definiert sind. Dazu gehören beispielsweise erfolgreich abgeschlossene Migrationen, freigegebene Smoke Tests, verfügbare Betriebsdokumentation, besetzter Support und bestätigte Kommunikationswege. „Keine kritischen Probleme bekannt“ ist kein belastbares Kriterium. Es beschreibt meist nur fehlende Transparenz.
Ebenso wichtig ist die Rollback-Entscheidung. Sie muss vor dem Start geklärt werden, nicht während eines Incidents. Das Projekt benötigt einen definierten Zeitpunkt, bis zu dem eine Rückkehr zum Altsystem technisch und fachlich möglich ist. Danach kann ein Rollback unter Umständen mehr Schaden verursachen als die kontrollierte Fehlerbehebung im Zielsystem.
Der Zielkonflikt ist real: Ein früher Rollback schützt den Betrieb, kann aber viel vorbereitete Arbeit verwerfen. Ein später Rollback kann Dateninkonsistenzen, Produktionsunterbrechungen oder lange Wiederanlaufzeiten verursachen. Die richtige Entscheidung hängt von Business Impact, Wiederherstellbarkeit und Qualität der Validierung ab. Deshalb sollten Fachbereich, IT-Betrieb, Security und Projektleitung ihre Entscheidungskriterien vorab gemeinsam festlegen.
Typische Fehler, die den Cutover verlängern
Die meisten Verzögerungen entstehen nicht erst im Cutover-Fenster. Sie werden Wochen vorher angelegt. Ein häufiger Fehler ist, offene Themen aus Zeitdruck in die Hypercare zu verschieben. Das kann bei kosmetischen Anpassungen sinnvoll sein. Bei Berechtigungen, Schnittstellen, Datenqualität oder Betriebsprozessen ist es riskant.
Ebenso problematisch sind unklare Rollen. Wenn externe Implementierungspartner, interne Fachbereiche und Betriebsteams jeweils davon ausgehen, dass jemand anderes die End-to-End-Validierung übernimmt, entsteht eine Lücke genau an der kritischen Übergabestelle. Eine zentrale Cutover-Leitung sorgt dafür, dass Aufgaben, Abhängigkeiten, Risiken und Entscheidungen an einer Stelle zusammenlaufen.
Auch Kommunikation wird oft unterschätzt. Anwender müssen wissen, wann Systeme nicht verfügbar sind, welche Prozesse ausgesetzt werden und wo sie Störungen melden. Der Service Desk benötigt bekannte Fehlerbilder, Eskalationswege und Ansprechpartner. Ohne diese Vorbereitung erscheinen normale Anlaufprobleme als unkontrollierte Störungslage.
So reduzieren Unternehmen Risiko und Dauer
Die schnellste Cutover-Strategie ist selten die mit dem kürzesten Kalendereintrag. Sie ist die mit der besten Wiederholbarkeit. Standardisierte Runbooks, klare Verantwortlichkeiten, automatisierte Prüfungen und ein realistisch getesteter Fallback reduzieren Wartezeiten und verhindern hektische Ad-hoc-Entscheidungen.
Bei größeren Transformationen empfiehlt sich ein gestaffeltes Vorgehen. Statt alle Standorte, Werke oder Prozessvarianten gleichzeitig umzustellen, kann ein Pilot die Annahmen validieren. Die daraus gewonnenen Laufzeiten, Fehlerbilder und Betriebsanforderungen fließen in die nächsten Wellen ein. Das senkt zwar nicht zwingend die Gesamtdauer des Programms, reduziert aber das Risiko eines flächendeckenden Ausfalls erheblich.
Erfahrene externe Projektleitung oder PMO-Unterstützung ist besonders dann sinnvoll, wenn mehrere Teams, Dienstleister und Entscheider koordiniert werden müssen. Die Aufgabe besteht nicht darin, zusätzliche Reports zu erzeugen. Sie besteht darin, den Cutover als steuerbares Ereignis aufzusetzen: mit integrierter Planung, belastbaren Entscheidungswegen, transparenten Risiken und konsequenter Nachverfolgung bis zur Betriebsstabilität.
Wer die Dauer eines Cutovers seriös einschätzen will, sollte nicht zuerst nach einem Standardwert fragen. Die bessere Frage lautet: Welche Nachweise brauchen wir, damit der Betrieb nach der Umstellung sicher weiterläuft? Aus dieser Antwort ergeben sich Zeitfenster, Ressourcenbedarf und die Qualität des gesamten Go-live-Plans.