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.

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.

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. Wer diese Phase improvisiert, 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.

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.