Das Problem, das ein belastbarer Cut-Over-Plan adressiert
Auf den Punkt: Der Cut-Over ist der Moment, in dem alle Annahmen aus dem Projektplan auf den Härtetest treffen. Ohne dokumentiertes Drehbuch wird aus einem geplanten Wochenende ein zweiwöchiges Provisorium — mit allen Folgekosten für Auftragsabwicklung, Buchhaltung und Lieferfähigkeit.
In den ersten zwölf Stunden nach Go-Live entscheidet sich, ob ein ERP-Projekt trägt oder in den Krisenmodus rutscht. Das Muster wiederholt sich: Software getestet, Schnittstellen dokumentiert, Projektplan freigegeben — und trotzdem kippt das Wochenende. Der Grund liegt fast nie in der Technik, sondern in fehlender Cut-Over-Disziplin: unklare Verantwortlichkeiten am Freitagabend, Stammdaten, die während der Migration noch konsolidiert werden, Schlüsselanwender, die nie eigenständig durch das neue System geführt haben.
Ein Cut-Over-Plan ist kein verlängerter Projektplan. Er ist ein eigenständiges Dokument, das jede Aktivität zwischen letztem Buchungstag im Altsystem und Freigabe für den Live-Betrieb stundengenau verankert: finale Datenmigration mit Validierungs-KPIs, Reihenfolge der Schnittstellen-Aktivierung, Eskalations- und Rückfallpfade, Kommunikation, Hypercare. Die Computerwoche hat sechs typische Scheiternsgründe von ERP-Projekten zusammengetragen — alle sechs kulminieren am Cut-Over-Wochenende.
Unsere Einordnung: Ein belastbarer Cut-Over-Plan ist die Versicherung gegen den Moment, in dem die Verantwortung von der IT zurück in den Fachbereich wandert. Aus über 1.200 Projekten wissen wir: das Drehbuch entscheidet, nicht das System.
Die Methodik im Überblick — vier Phasen für einen tragfähigen Cut-Over
Auf den Punkt: Wir gliedern jeden Cut-Over in vier Phasen: Cleansing, Mock-Cutover, Go-Live-Wochenende und Hypercare. Jede Phase hat eigene Exit-Kriterien, eigene Verantwortliche und eigene KPIs. Wer eine Phase abkürzt, holt die Zeit in der nächsten doppelt auf.
Phase 1 — Daten-Cleansing und Stammdaten-Konsolidierung (6–9 Monate vor Go-Live). Material-, Kunden- und Lieferantenstämme werden in einer festen Reihenfolge konsolidiert, dedupliziert und um Pflichtfelder ergänzt. Diese Vorlaufzeit ist nicht verhandelbar — die Konsequenzen verkürzter Cleansing-Phasen sehen wir später in falschen Bewertungen, blockierten Bestellanforderungen und manuellen Nacharbeiten.
Phase 2 — Mock-Cutover (8–12 Wochen vor Go-Live). Ein vollständiger Probelauf der Cut-Over-Choreografie in einer Sandbox. Der SAP-Leitfaden zum Project Cutover macht den Mock-Cutover verpflichtend, und unsere Erfahrung deckt sich damit: erst der dritte Probelauf bringt belastbare Zeiten und deckt die Lücken auf, die im zweiten noch unter dem Radar liefen.
Phase 3 — Go-Live-Wochenende (typischerweise Freitagabend bis Montagmorgen). Stundengenaue Choreografie mit fest definierten Go/No-Go-Punkten, Entscheidungsbäumen für Rückfall-Szenarien und einem War-Room mit klarer Sprecherrolle. Hier zahlt jede Probe aus Phase 2 ein.
Phase 4 — Hypercare (4–8 Wochen nach Go-Live). Erhöhte Support-Dichte, tägliche Stand-ups, KPI-Dashboards für Auftragsdurchlauf, Buchungsfähigkeit und Schnittstellen-Volumen. Erst wenn die KPIs zwei Wochen in Folge im grünen Bereich liegen, übergeben wir in den Regelbetrieb. Die Fraunhofer-IAO-Studie zu Erfolgskriterien betrieblicher Digitalisierung bestätigt diese Reihenfolge: Der technische Go-Live ist nur der Anfang, Prozessstabilität entsteht erst in der Nachbereitung.
Unsere Einordnung: Die vier Phasen sind keine Methoden-Folklore, sondern Risikoabschirmung. Jede übersprungene Phase verlagert ihren Aufwand in die nächste — und zwar mit Zinsen.
Praxisbeispiel: Maschinenbauer aus Süddeutschland, rund 900 Mitarbeitende
Auf den Punkt: Ein Maschinenbauer mit drei Werken in Süddeutschland, etwa 900 Mitarbeitenden und zwei Buchungskreisen löste ein gewachsenes Eigenentwicklungs-ERP ab. Der Cut-Over lief über ein einziges Wochenende; alle KPIs lagen am dritten Werktag im grünen Bereich. Entscheidend war eine Train-the-Trainer-Kaskade mit 28 Multiplikatorinnen und Multiplikatoren.
Wir haben in einem Projekt mit einem mittelständischen Maschinenbauer aus Süddeutschland (rund 900 Mitarbeitende, drei Werke, zwei Buchungskreise) den Cut-Over über vier Monate vorbereitet — der Daten-Cleansing-Horizont betrug sieben Monate, der Hypercare-Stab umfasste neun FTE. Die Ausgangslage war typisch für den DACH-Mittelstand: gewachsene Systemlandschaft, lokale Sonderlocken je Werk, kritische Materialwirtschaft mit Just-in-Sequence-Anbindung an zwei Großkunden. Reine Big-Bang-Logik wäre zu riskant gewesen — eine Phased-Variante über zwölf Monate hätte die Schnittstellen-Komplexität verdoppelt. Wir entschieden uns für einen Hybrid: Buchungs- und Produktionsfunktionen im Big-Bang, Reporting und Personalwesen in zwei klar getakteten Wellen.
Die größte Investition floss in die Vorbereitung. Sieben Monate vor Go-Live begann das Daten-Cleansing — Materialstämme, dann Lieferanten, dann Kunden, am Schluss Konditionen. Acht Wochen vor dem Wochenende lief der erste Mock-Cutover, fünf Wochen vorher der zweite, zwei Wochen vorher der dritte. Erst der dritte traf die Soll-Zeiten. Die 28 ausgebildeten Multiplikatorinnen und Multiplikatoren — je ein Schlüsselanwender pro Bereich und Schicht — schulten in den letzten drei Wochen rund 700 Endanwenderinnen und Endanwender. Am Go-Live-Wochenende waren in jeder Schicht mindestens zwei Multiplikatoren vor Ort.
Ergebnis: 11 Prozent weniger geplante Cut-Over-Zeit, null Rückfälle, vier statt acht Wochen Hypercare. Das Monatsabschluss-KPI lag bereits im ersten Monatslauf nach Go-Live im grünen Bereich.
Unsere Einordnung: Der Erfolg lag nicht in der Software-Wahl, sondern in der Disziplin der Vorarbeit. Drei Mock-Cutovers, sieben Monate Cleansing, 28 Multiplikatoren — keine dieser Investitionen war optional.
Häufige Fehler bei Cut-Over-Plänen
Auf den Punkt: Fünf Fehler sehen wir in fast jedem zweiten Projekt: zu spätes Cleansing, fehlende Mock-Cutovers, unklare Go/No-Go-Kriterien, ein unterbesetzter Hypercare und ein Rückfallplan, der nie geprobt wurde. Jeder dieser Fehler kostet im Zweifel zwei bis vier Wochen Produktivitätsausfall.
- Cleansing-Beginn zu spät. Wer drei Monate vor Go-Live mit der Bereinigung der Stammdaten startet, hat die Tiefe nicht erreicht. Sechs bis neun Monate sind im Mittelstand der belastbare Korridor.
- Mock-Cutover als Formalität. Ein einziger Probelauf, der „irgendwie durchläuft“, ersetzt keinen echten Test. Wir planen drei Mock-Cutovers; das hat sich aus über 1.200 Projekten als Untergrenze etabliert.
- Weiche Go/No-Go-Kriterien. „Wir entscheiden am Sonntagmittag“ ist keine Entscheidungsregel. Kriterien müssen quantitativ sein: Migrationsvolumen, Fehlerraten, Schnittstellenstatus, fachliche Stichproben — jeweils mit Schwellwerten.
- Hypercare als Pflichtübung. Wer Hypercare nach zwei Wochen beendet, weil „alles läuft“, verkennt, dass viele Engpässe erst im Monatsabschluss sichtbar werden. Vier bis acht Wochen sind der Standard.
- Rückfallplan ohne Probe. Ein Rückfallplan, der nie unter realistischen Bedingungen getestet wurde, ist Papier. Wir proben den Rückfall im zweiten oder dritten Mock-Cutover mit voller Konsequenz.
Unsere Einordnung: Aus über 1.200 Projekten wissen wir, dass diese fünf Fehler selten Folge mangelnder Sorgfalt sind. Sie entstehen unter Budgetdruck im letzten Projektdrittel — und dort, wo die unabhängige Sicht eines erfahrenen Beraters fehlt. Auch die SAP-Activate-Methodik, die DSAG-Leitlinien zur Migration und die Bitkom-Empfehlungen zu Bildung und Arbeit verweisen auf dieselben Mechanismen.
Anwendung in Maschinenbau, Bauindustrie und Fertigung
Auf den Punkt: Branchen unterscheiden sich nicht in der Cut-Over-Methodik, sondern in den Engpässen. Maschinenbau hat seinen Engpass in der Fertigungsfeinplanung, die Bauindustrie in der Projektabrechnung, die Fertigung in den Schnittstellen zur Linie. Wer das Muster kennt, plant den Cut-Over um den Engpass herum.
Im Maschinenbau ist die Fertigungsfeinplanung der kritische Pfad. Wir planen Cut-Overs hier so, dass die offenen Produktionsaufträge vor dem Wochenende sauber abgeschlossen werden und die ersten zwei Wochen Hypercare einen Auftragsbestand abbilden, der noch unter realistischen Bedingungen entsteht. Just-in-Sequence-Anbindungen testen wir im dritten Mock-Cutover mit Live-Daten der Kunden.
In der Bauindustrie dominiert die Projektabrechnung. Cut-Overs auf den Monatsersten oder das Quartalsende sind hier in der Regel keine Option — Teilabrechnungen, Bautagebücher und Nachträge laufen kontinuierlich. Wir wählen Cut-Over-Zeitpunkte, die zwischen Abschluss-Stichtagen liegen, und ziehen die Hypercare-Phase über mindestens einen vollständigen Monatsabschluss.
In der diskreten und prozessorientierten Fertigung sind die Schnittstellen zur Produktionslinie der Engpass. MES-Anbindungen, Wiegesysteme, Etiketten- und Versanddrucker — jede dieser Schnittstellen ist im Mock-Cutover separat zu testen. Der Microsoft-Dynamics-365-Cutover-Leitfaden beschreibt die Bedeutung des Mock-Cutovers für genau diese Konstellationen — wir gehen einen Schritt weiter und proben Schnittstellen unter realistischer Lastkurve. Mit Blick auf die EU-AI-Act-Vorgaben seit Februar 2026 gilt das auch für KI-gestützte ERP-Module wie Prognose- und Bedarfsplanung — Konformitätsnachweise gehören in die Hypercare-Checkliste.
Wie wir unsere Methodik in der Praxis einsetzen: KI-gestützte Werkzeuge sind in der Datenanalyse vor dem Cut-Over hilfreich — die Mustererkennung über mehrere Mittelstands-Projekte hinweg. Die Übersetzung eines Stammdatenbefunds in eine konkrete Cleansing-Reihenfolge bleibt eine Beraterleistung. Aus über 1.200 Projekten wissen wir: Wir nutzen unsere Cut-Over-Methodik, um die Anforderungen früh im Projekt zu strukturieren — diese frühe Strukturierung verkürzt später die Mock-Cutover-Schleifen messbar.
Unsere Einordnung: Die Methodik ist branchenagnostisch — der Engpass nicht. Wer die branchenspezifische Engpass-Frage vor dem Cut-Over beantwortet, plant um die Schwachstelle herum, nicht in sie hinein.
Häufig gestellte Fragen
Spätestens neun Monate vor dem geplanten Go-Live. In den ersten drei Monaten geht es um die Cut-Over-Strategie — also die Grundsatzentscheidung zwischen Big-Bang, phasenweise oder hybrid sowie um den Daten-Cleansing-Fahrplan. Der eigentliche Cut-Over-Plan mit stundengenauer Choreografie entsteht in den letzten drei Monaten, gespeist aus den Erkenntnissen der Mock-Cutovers. Wer später beginnt, riskiert, dass die Cleansing-Phase und die Mock-Cutover-Schleifen nicht mehr in den verfügbaren Zeitkorridor passen — und dann unter Druck abgekürzt werden.
Vier bis acht Wochen, in der Regel vier Wochen bei homogenen Mittelständlern und acht Wochen, wenn mehrere Werke, Buchungskreise oder kritische Schnittstellen betroffen sind. Entscheidend ist nicht die Kalenderdauer, sondern das KPI-Ergebnis: Erst wenn Auftragsdurchlauf, Buchungsfähigkeit und Schnittstellenvolumen zwei Wochen in Folge im grünen Bereich liegen — und mindestens ein Monatsabschluss sauber durchgelaufen ist — übergeben wir in den Regelbetrieb. Vorher endet Hypercare nicht.
Bei einem Werk, einem Buchungskreis und einer Schicht ist der Big-Bang regelmäßig die effizienteste Variante. Ab zwei Werken oder zwei Buchungskreisen werden hybride Modelle vorteilhaft — Buchung und Kernfunktionen im Big-Bang, Reporting und Nebenprozesse phasenweise. Ab vier Werken oder drei Buchungskreisen ist ein reiner Big-Bang nur noch mit erheblich vergrößerter Hypercare-Mannschaft verantwortbar; die phasenweise Einführung ist hier in der Regel die bessere Wahl.
Nächste Schritte
Wenn Sie eine ERP-Einführung planen oder mitten in der Vorbereitung stecken, beginnen Sie mit einer ehrlichen Bestandsaufnahme: Wie weit ist Ihr Daten-Cleansing? Wie viele Mock-Cutovers sind realistisch noch durchführbar? Welche Multiplikatoren-Struktur existiert bereits in Ihren Werken? Wir begleiten mittelständische Unternehmen seit 1992 durch ERP-Einführungen und stellen unsere Praxis aus über 1.200 Projekten zur Verfügung — von der ERP-Auswahl über die ERP-Einführung bis zum stabilen Live-Betrieb. Ergänzend zur Cut-Over-Diskussion empfehlen wir auch unsere Wiki-Beiträge zu Business Process Owner, PDCA und Prozessanalyse. Ein erstes Gespräch ist kostenfrei und führt zu einer ehrlichen Einschätzung — nicht zu einem Angebot mit Methodenüberbau.
