ERP-Cutover-Planung: Was zwischen dem letzten Test und dem ersten produktiven Tag passieren muss

Der Cutover ist der Übergang vom alten System zum neuen. Es ist der Moment, in dem das Unternehmen von dem ERP-System, das es kennt, auf das wechselt, das es einführen will. Dieser Wechsel ist nicht nur ein technischer Akt, es ist ein organisatorischer Einschnitt, der Vorbereitung erfordert.

In der Praxis umfasst der Cutover eine Vielzahl von Aufgaben, die in einer genau definierten Reihenfolge abgearbeitet werden müssen: Datenmigration, Schnittstellenumschaltung, Berechtigungsvergabe, Systemfreigabe, erste Transaktionen im Produktivsystem. Jede dieser Aufgaben hat Abhängigkeiten und Zeitfenster. Wenn ein Schritt scheitert, hat das Auswirkungen auf alle folgenden.

Der Go-Live ist der Moment, in dem das neue ERP-System produktiv gesetzt wird und den realen Geschäftsbetrieb übernimmt. Der Cutover ist der gesteuerte Übergangsprozess davor und danach: alle Aktivitäten, die den Wechsel vom alten auf das neue System vorbereiten, durchführen und absichern. Kurz gesagt: Der Go-Live ist ein Zeitpunkt, der Cutover ist ein Prozess.

Im Projektalltag werden beide Begriffe oft synonym verwendet, das führt zu Missverständnissen. Wer vom Go-Live spricht, meint den Stichtag der Produktivsetzung, auch Produktivstart genannt. Wer vom Cutover spricht, meint die gesamte Umstellungsphase: von der finalen Datenmigration über die Schnittstellenumschaltung bis zur Stabilisierung in den ersten Tagen des Produktivbetriebs. Der Go-Live ist damit ein Meilenstein innerhalb des Cutover, nicht dasselbe.

Diese Unterscheidung ist mehr als Begriffshygiene. Sie bestimmt, wie geplant wird: Ein Go-Live-Termin lässt sich in den Kalender schreiben, ein Cutover muss als Prozess mit Abhängigkeiten, Verantwortlichkeiten und Rückfallpositionen gesteuert werden. Wer nur den Termin plant, plant den kleinsten Teil der Umstellung.

Die grundlegendste Entscheidung der Cutover-Planung ist die Rollout-Strategie. Beide Ansätze haben Vor- und Nachteile, und die richtige Wahl hängt von der Unternehmensstruktur ab.

Beim Big Bang werden alle Standorte, Bereiche und Module gleichzeitig umgestellt. Das alte System wird abgeschaltet, das neue geht für alle live. Der Vorteil: Es gibt nur einen Cutover, keine Schnittstellen zwischen altem und neuem System, und das Projekt ist nach dem Go-Live abgeschlossen. Der Nachteil: Das Risiko konzentriert sich auf einen einzigen Zeitpunkt. Wenn etwas schiefgeht, betrifft es sofort das gesamte Unternehmen.

Big-Bang eignet sich für Unternehmen mit stark integrierten Prozessen, bei denen ein Parallelbetrieb zweier Systeme zu aufwendig wäre. Die Voraussetzung ist eine gründliche Vorbereitung, insbesondere in der Testphase und bei der Datenmigration.

Beim Phasen-Rollout wird stufenweise umgestellt, entweder nach Standorten, Bereichen oder Modulen. Der Vorteil: Das Risiko wird verteilt, Erfahrungen aus der ersten Phase fließen in die folgenden ein, und das Unternehmen kann schrittweise lernen. Der Nachteil: Für die Dauer des Rollouts müssen zwei Systeme parallel betrieben werden, inklusive der Schnittstellen zwischen ihnen.

Phasen-Rollouts eignen sich für Unternehmen mit mehreren Standorten oder klar trennbaren Geschäftsbereichen. Wichtig ist, dass die Reihenfolge der Phasen durchdacht ist: Welcher Standort oder Bereich eignet sich als Pilot? Wo ist das Risiko am geringsten und der Lerneffekt am größten?

Ein Cutover-Plan ist im Kern eine zeitlich geordnete Checkliste mit klaren Verantwortlichkeiten. Die folgenden Bereiche müssen abgedeckt sein:

Die finale Datenmigration ist oft der zeitkritischste Schritt im Cutover. Stammdaten (Kunden, Lieferanten, Artikel) können vorab migriert werden, aber Bewegungsdaten (offene Bestellungen, Lagerbestände, offene Posten) müssen zum Stichtag übernommen werden. Der Zeitbedarf für die Migration muss in einer Generalprobe ermittelt und im Cutover-Plan berücksichtigt werden.

Alle Benutzer müssen im neuen System mit den richtigen Berechtigungen angelegt sein. Das klingt trivial, ist aber in der Praxis eine häufige Fehlerquelle: Mitarbeiter können sich nicht anmelden, haben zu wenige oder zu viele Rechte, oder kritische Funktionen sind nicht zugänglich. Berechtigungskonzepte sollten vor dem Cutover getestet und dokumentiert sein.

Alle Schnittstellen zu externen Systemen, Webshop, EDI-Partner, Kassensysteme, Bankverbindungen, BI-Tools, müssen zum Go-Live umgeschaltet werden. Das erfordert Koordination mit externen Partnern und muss zeitlich genau abgestimmt sein. Für jede Schnittstelle braucht es einen Ansprechpartner und einen Testlauf.

Was passiert, wenn der Go-Live scheitert? Gibt es einen Punkt, bis zu dem ein Rollback möglich ist? Unter welchen Bedingungen wird ein Rollback ausgelöst? Diese Fragen müssen vor dem Cutover beantwortet sein, nicht erst, wenn das Problem auftritt.

Eine Fallback-Strategie ist keine Schwäche, sie ist professionelles Risikomanagement. Sie definiert Go/No-Go-Kriterien und stellt sicher, dass die Entscheidungsträger wissen, wann und wie sie eingreifen müssen.

Wer wird wann über den Cutover informiert? Mitarbeiter, Kunden, Lieferanten, Partner, alle sind betroffen und müssen wissen, was auf sie zukommt. Ein Kommunikationsplan für den Cutover-Zeitraum ist kein Nice-to-have, sondern eine operative Notwendigkeit.

Die Wahl des Cutover-Zeitpunkts ist strategisch. In vielen Unternehmen bietet sich ein Wochenende oder ein verlängertes Wochenende an, um den Cutover mit minimaler Beeinträchtigung des Tagesgeschäfts durchzuführen. Im Handel kann das Ende einer umsatzschwachen Phase sinnvoll sein, ein Cutover mitten im Weihnachtsgeschäft ist in der Regel keine gute Idee.

Entscheidend ist, dass das Zeitfenster realistisch bemessen ist. Dafür braucht es eine Generalprobe (den Dry Run), die zeigt, wie lange die einzelnen Schritte tatsächlich dauern. Ohne Dry Run ist jede Zeitplanung Spekulation.

Ob ein ERP-Projekt live geht, ist keine Bauchentscheidung und kein Automatismus, weil der Termin nun einmal im Kalender steht. Es ist eine unternehmerische Entscheidung auf Basis vorher definierter Kriterien. Genau dafür gibt es die Go/No-Go-Entscheidung: einen festen Termin kurz vor dem geplanten Go-Live, an dem die Verantwortlichen anhand des Kriterienkatalogs prüfen, ob das Projekt bereit ist.

Die Go-Live-Entscheidung gehört auf die Führungsebene: in den Lenkungsausschuss oder direkt zur Geschäftsführung. Die Projektleitung bereitet die Entscheidung vor, indem sie den Status jedes Kriteriums transparent macht, inklusive der Punkte, die nicht erfüllt sind. Entscheidend ist die Trennung von Rollen: Wer das System implementiert, sollte die Reife nicht allein bewerten. Eine unabhängige Instanz, die weder an Lizenzen noch am Implementierungsaufwand verdient, schafft hier die neutrale Sicht, die eine belastbare Entscheidung braucht.

Ein No-Go ist dabei kein Scheitern, sondern gelebte Governance. Ein um Wochen verschobener Go-Live kostet Geld und Momentum. Ein erzwungener Go-Live mit ungelösten kritischen Punkten kostet beides auch, zusätzlich aber Vertrauen bei Mitarbeitern, Kunden und Lieferanten. Die Entscheidungskriterien vorher festzulegen nimmt der Diskussion am Stichtag die Emotion.

Zu jeder Go-Entscheidung gehört die Antwort auf die Frage: Was passiert, wenn es nach dem Go-Live doch nicht funktioniert? Der Rollback-Plan definiert, bis zu welchem Zeitpunkt eine Rückkehr zum Altsystem möglich ist, wer sie auslösen darf und wie sie technisch abläuft. Nach diesem Punkt gibt es nur noch den Weg nach vorn, dann muss das Hypercare-Konzept tragen. Beide Szenarien müssen vor dem Stichtag durchdacht sein, nicht erst im Krisenmodus.

Der Go-Live ist nicht das Ende des Projekts, es ist der Beginn der kritischsten Betriebsphase. In den ersten ein bis zwei Wochen nach dem Go-Live treten die Probleme auf, die trotz guter Testarbeit nicht vorhergesehen wurden: Sonderfälle, die in keinem Testszenerio vorkamen, Benutzer, die mit dem neuen System nicht zurechtkommen, Schnittstellen, die unter Reallast anders reagieren als im Test.

Ein guter Cutover-Plan ist mehr als eine Checkliste. Er ist ein Führungsinstrument, das Klarheit schafft: Wer macht was, wann und in welcher Reihenfolge? Welche Entscheidungen müssen wann getroffen werden? Was sind die Kriterien für ein Go oder No-Go?

Diese Klarheit reduziert Stress, für die Geschäftsführung, die wissen will, ob der Go-Live sicher ist, für das Projektteam, das unter Druck arbeitet, und für die Mitarbeiter, die wissen wollen, was auf sie zukommt.

Der Cutover ist die Verdichtung des gesamten ERP-Projekts in wenige Tage. Was in Monaten der Vorbereitung aufgebaut wurde, wird hier auf die Probe gestellt. Diese Phase zu improvisieren, verschenkt die Arbeit der vorangegangenen Monate.

Ein strukturierter Cutover-Plan mit klaren Verantwortlichkeiten, einem getesteten Zeitplan, einer Fallback-Strategie und einem Hypercare-Konzept ist keine Überversicherung, er ist die Voraussetzung dafür, dass der Go-Live gelingt und das neue System vom ersten Tag an Mehrwert liefert.

Go-Live bezeichnet den Zeitpunkt, an dem ein neues System produktiv gesetzt wird und den realen Geschäftsbetrieb übernimmt. Im ERP-Kontext ist das der Stichtag, ab dem alle Buchungen und Transaktionen im neuen System laufen und das Altsystem abgelöst wird. Der Go-Live ist ein Meilenstein, kein Projektende: Danach folgt die Hypercare-Phase, in der das System im Echtbetrieb stabilisiert wird.

Der Go-Live ist ein Zeitpunkt, der Cutover ist ein Prozess. Der Cutover umfasst alle gesteuerten Aktivitäten rund um die Systemumstellung: finale Datenmigration, Schnittstellenumschaltung, Systemfreigabe und die Stabilisierung danach. Der Go-Live ist der Moment innerhalb dieses Prozesses, an dem das neue System offiziell den Produktivbetrieb übernimmt.

Wenn die vorher definierten Go/No-Go-Kriterien erfüllt sind: Die Datenmigration ist geprüft, die kritischen Geschäftsprozesse sind im Zielsystem erfolgreich getestet, alle geschäftskritischen Schnittstellen laufen, die Benutzer sind mit korrekten Berechtigungen angelegt, es gibt keine offenen Fehler der höchsten Prioritätsklasse und das Hypercare-Team steht bereit. Die Entscheidung trifft der Lenkungsausschuss oder die Geschäftsführung auf Basis dieser Kriterien, nicht das Bauchgefühl am Stichtag.

Das hängt von der Komplexität ab. Für mittelständische Handelsunternehmen mit einem System dauert der eigentliche Cutover typischerweise ein bis drei Tage, oft über ein Wochenende. Die Vorbereitung (vorab-migrierte Stammdaten, Berechtigungen, Schnittstellentests) beginnt jedoch Wochen vorher. Der Hypercare-Zeitraum danach dauert in der Regel zwei bis vier Wochen.

Unbedingt. Ein Dry Run (Generalprobe) ist der wichtigste Einzelschritt in der Cutover-Vorbereitung. Er zeigt, wie lange die Migration tatsächlich dauert, deckt Probleme auf, die in der Planung nicht sichtbar waren, und gibt dem Team Sicherheit für den Ernstfall. Idealerweise findet der Dry Run zwei bis vier Wochen vor dem geplanten Go-Live statt, damit genug Zeit für Korrekturen bleibt.

Ein Rollback ist das letzte Mittel und sollte nur dann ausgelöst werden, wenn kritische Geschäftsprozesse nicht funktionieren und keine kurzfristige Behebung möglich ist. Typische Auslöser: fehlerhafte Datenmigration, die sich nicht korrigieren lässt, Schnittstellenprobleme, die den Geschäftsbetrieb blockieren, oder fundamentale Funktionslücken, die im Test übersehen wurden. Wichtig: Der Rollback muss vorher definiert und getestet sein, wenn man ihn braucht, ist keine Zeit mehr für Improvisation.