Der Go-live-Termin steht, mehrere Testmigrationen sind gelaufen – und trotzdem besteht der Cutover noch aus einer groben Aufgabenliste. Darin stehen Punkte wie „Daten exportieren“, „Import starten“ und „Fachbereich prüft“. Was fehlt, sind belastbare Laufzeiten, eindeutige Übergaben, konkrete Prüfergebnisse und eine vorab entschiedene Reaktion auf Abweichungen.
In dieser Situation hilft kein längerer Terminplan. Ein ERP Cutover Plan muss die Datenmigration so präzise beschreiben, dass das Projekt den produktiven Lauf unter Zeitdruck ausführen, überwachen und freigeben kann. Dafür verbindet er die technische Ablaufsteuerung mit fachlichen Entscheidungen: Wann endet die Datenerfassung im Altsystem? Welcher Datenstand wird übernommen? Wer bestätigt die Vollständigkeit? Bis zu welchem Zeitpunkt ist ein Rückfall noch möglich? Und wer entscheidet, ob das neue ERP für den Geschäftsbetrieb freigegeben wird?
Dieser Beitrag richtet sich an ERP-Projektleitungen und IT-Verantwortliche, deren Go-live näher rückt. Er zeigt, wie aus Testläufen ein ausführbarer Cutover-Plan entsteht, welche Datenmigrationsrisiken darin sichtbar sein müssen und woran Sie erkennen, ob das Projekt für den produktiven Lauf tatsächlich bereit ist.
Ein Cutover-Plan ist mehr als die letzte Seite des Projektplans
Der allgemeine Projektplan steuert Meilensteine über Wochen und Monate. Der Cutover-Plan steuert dagegen einen begrenzten Übergangszeitraum, in dem viele voneinander abhängige Schritte ohne beliebige Wiederholungsmöglichkeit ausgeführt werden. Für die Datenmigration reicht deshalb eine Zeile mit Start- und Enddatum nicht aus.
Drei Ebenen sollten klar getrennt werden:
- Cutover-Strategie: Sie legt den grundsätzlichen Übergang fest – beispielsweise Big Bang oder gestufter Rollout, verfügbares Zeitfenster, Datenstopp, Voll- oder Deltaläufe und Entscheidungswege.
- ERP Cutover Plan: Er bringt sämtliche fachlichen, technischen und organisatorischen Aufgaben in eine ausführbare Reihenfolge mit Zeiten, Abhängigkeiten, Verantwortlichen und Entscheidungspunkten.
- Migrations-Runbook: Es beschreibt die konkrete Ausführung der Datenmigration: verwendete Eingaben und Versionen, Extraktions- und Transformationsschritte, Ladefolgen, Kontrollen, Protokolle und Wiederanlauf.
Diese Ebenen gehören zusammen, sind aber nicht austauschbar. Ein detailliertes SQL-Skript ersetzt keine Go-/No-go-Regel. Eine Go-live-Checkliste erklärt wiederum nicht, mit welchem Datenstand ein fehlgeschlagener Ladeschritt wiederholt werden kann.
Microsoft nennt für einen Cutover-Plan unter anderem Reihenfolge und Zeitplanung, Aufgabenverantwortliche und Vertretungen, Ausführungsanweisungen, Verifikation, Freigabe sowie einen Rückfallplan. Außerdem soll der Ablauf vor dem Produktivstart möglichst realitätsnah geprobt werden. Diese Grundstruktur ist nicht auf ein bestimmtes ERP-System beschränkt und entspricht dem, was eine Datenmigration unter Zeitdruck steuerbar macht.
Bevor die Planung detailliert wird, muss die Migration wiederholbar sein
Ein Cutover-Plan kann keinen instabilen Migrationsprozess reparieren. Wenn die letzte Testdatei nur durch spontane manuelle Korrekturen importiert werden konnte, ist der produktive Ablauf noch nicht planbar. Das Gleiche gilt, wenn Datenobjekte, Transformationsregeln oder fachliche Prüfkriterien weiterhin grundsätzlich offen sind.
Vor der belastbaren Cutover-Planung sollten mindestens folgende Voraussetzungen vorliegen:
- Der produktiv benötigte Datenumfang ist je Datenobjekt entschieden.
- Quellen, Zielstrukturen und Abhängigkeiten sind bekannt.
- Mapping- und Transformationsregeln besitzen einen freigegebenen Versionsstand.
- Extraktion, Aufbereitung und Übergabe an das Zielsystem sind reproduzierbar.
- Mehrere relevante Testläufe wurden technisch und fachlich geprüft.
- Laufzeiten wurden mit realistischen Datenmengen gemessen.
- Offene Abweichungen sind bewertet, terminiert und einem Verantwortlichen zugeordnet.
Auch SAP beschreibt als Voraussetzung für den Cutover, dass Testläufe durchgeführt, Daten im Testsystem validiert und die für den Produktivlauf benötigten Extrakte beziehungsweise Ladedateien vorbereitet wurden. Ein anstehender Termin ist damit kein Reifegrad. Die nachweisbare Beherrschung des Ablaufs ist der Reifegrad.
Fehlen noch Scope, Mapping oder wiederholbare Testläufe, liegt der Engpass vor dem Cutover. Unser Fahrplan für die Datenmigration in sieben Phasen hilft dabei, die früheste noch nicht belastbare Projektphase zu bestimmen. Sind dagegen Ablauf und Testergebnisse grundsätzlich stabil, lohnt sich die detaillierte Cutover-Planung.
Welche Informationen jede Cutover-Aufgabe enthalten sollte
Eine gute Cutover-Zeile beantwortet nicht nur, was zu tun ist. Sie macht auch erkennbar, wann die Aufgabe beginnen darf, welches Ergebnis sie erzeugt und wie dieses Ergebnis bestätigt wird.
| Feld | Frage, die beantwortet werden muss |
|---|---|
| Aufgabe | Welcher konkrete, ausführbare Schritt wird durchgeführt? |
| Voraussetzung | Welches Ergebnis oder welche Freigabe muss vorher vorliegen? |
| Planzeit | Wann beginnt die Aufgabe und wie lange darf sie dauern? |
| Verantwortung | Wer führt aus, wer vertritt und wer entscheidet bei Abweichungen? |
| Eingabe und Version | Welcher Datenstand, welches Skript und welche Konfiguration werden verwendet? |
| Ergebnis | Welche Datei, welches Protokoll oder welcher Systemzustand muss entstehen? |
| Prüfung | Wie wird technische Vollständigkeit oder fachliche Richtigkeit festgestellt? |
| Entscheidung | Wer gibt den nächsten Schritt frei und welche Kriterien gelten? |
| Fehlerweg | Wird korrigiert, wiederholt, eskaliert, zurückgefallen oder kontrolliert weitergearbeitet? |
Die Spalten können in Excel, einem Projektwerkzeug oder einem spezialisierten Cutover-System geführt werden. Entscheidend ist nicht das Werkzeug, sondern die Eindeutigkeit. „Fachbereich prüft“ ist zu ungenau. „Vertriebsleitung bestätigt Anzahl und Summe der offenen Kundenaufträge anhand der freigegebenen Vergleichsauswertung“ ist ausführbar und prüfbar.
Die Datenmigration braucht im Cutover eine eigene Ablaufkette
Der Gesamt-Cutover enthält neben der Datenmigration auch Systembereitstellung, Berechtigungen, Schnittstellen, Kommunikation, Schulung und Betriebsübergabe. Innerhalb dieses Gesamtplans sollte die Datenmigration als zusammenhängende Ablaufkette erkennbar bleiben. Sonst verschwinden wichtige Abhängigkeiten zwischen einzelnen technischen Aufgaben.
Eine typische Reihenfolge umfasst:
- Änderungsstopp oder klar definierter Stichtag: Das Projekt legt fest, welche Vorgänge im Altsystem noch abgeschlossen werden und ab wann der produktive Datenstand nicht mehr unkontrolliert verändert werden darf.
- Quellnachweise sichern: Mengen, Summen und fachlich relevante Abschlussauswertungen werden aus dem Altsystem erzeugt. Sie bilden später die Vergleichsbasis.
- Finale Extraktion ausführen: Vollbestand oder Delta werden mit der freigegebenen Logik erzeugt und eindeutig versioniert.
- Daten transformieren und prüfen: Die vereinbarten Regeln werden reproduzierbar angewendet. Vor dem Import werden Struktur, Pflichtfelder, Beziehungen und erwartete Mengen kontrolliert.
- Objekte in der richtigen Reihenfolge laden: Stammdaten, abhängige Objekte, Bestände und offene Vorgänge werden entsprechend den Zielabhängigkeiten verarbeitet.
- Technisch abstimmen: Ladeprotokolle, Fehlermengen, Schlüssel, Summen und Beziehungen werden gegen die vereinbarten Kriterien geprüft.
- Fachlich validieren: Benannte Keyuser prüfen kritische Daten und Geschäftsvorgänge im Zielsystem.
- Freigeben oder eskalieren: Das Entscheidungsgremium bewertet die vorliegenden Nachweise gegen die vorab vereinbarten Go-/No-go-Kriterien.
- In die Stabilisierung übergeben: Akzeptierte Restpunkte, Verantwortliche, Prioritäten und Kontrollaufgaben für die ersten Betriebstage werden dokumentiert.
Diese Reihenfolge ist kein universelles Rezept. Je nach ERP-System, Datenumfang und Rollout können Vorladungen, mehrere Deltawellen oder parallele Objektgruppen sinnvoll sein. Der Plan muss die konkrete Migrationsarchitektur abbilden – nicht eine allgemeine Vorlage unverändert übernehmen.
Voll- oder Deltalauf: Der Datenstopp muss fachlich und technisch zusammenpassen
Die Entscheidung zwischen vollständigem Produktivlauf und Delta ist eine der wichtigsten Cutover-Fragen. Sie lässt sich nicht allein anhand der Datensatzmenge beantworten. Relevant sind auch Extraktions- und Ladezeit, zulässige Betriebsunterbrechung, Änderungsvolumen, Löschungen, Rückdatierungen, technische Selektionsmöglichkeiten und die Frage, ob ein bereits vorgeladener Bestand sicher aktualisiert werden kann.
Ein vollständiger Lauf ist attraktiv, wenn er innerhalb des verfügbaren Fensters reproduzierbar ausgeführt und geprüft werden kann. Er reduziert die Komplexität der Delta-Ermittlung. Ist das Datenvolumen dafür zu groß, kann eine Vorladung mit anschließenden Deltaläufen das Cutover-Fenster entlasten. Dann muss das Projekt jedoch exakt festlegen:
- nach welchem Zeitstempel, Status oder fachlichen Merkmal Änderungen erkannt werden,
- wie neue, geänderte und gelöschte Datensätze behandelt werden,
- wie verspätet erfasste oder rückdatierte Vorgänge erkannt werden,
- ob ein Delta gefahrlos erneut verarbeitet werden kann und
- wie Quelle, Vorladung und finaler Zielstand miteinander abgestimmt werden.
Die aktuelle Microsoft-Leitlinie zur Datenmigrationsplanung für den Go-live hebt ebenfalls gemessene Laufzeiten, Voll- und Deltaläufe, einen konsistenten Datenstand sowie klare Kommunikation hervor. Für das konkrete Projekt bleibt trotzdem zu entscheiden, welche Logik fachlich vollständig und technisch beherrschbar ist.
Auch der Datenstopp braucht Präzision. „Freitagabend ist Freeze“ beantwortet nicht, ob Nutzer nur nicht mehr buchen dürfen, ob Schnittstellen gestoppt werden, ob automatische Jobs weiterlaufen oder wie unvermeidbare Notfälle dokumentiert werden. Der Cutover-Plan muss daher benennen, welche Systeme und Prozesse betroffen sind, wer den Stopp bestätigt und wie Ausnahmen in den finalen Datenstand gelangen.
Die Generalprobe macht aus Schätzungen belastbare Planzeiten
Die Generalprobe ist kein zusätzlicher Testimport mit bekannten Beispieldaten. Sie soll den produktiven Ablauf unter möglichst vergleichbaren Bedingungen proben. Dazu gehören realistische Datenmengen, die vorgesehenen Skripte und Werkzeuge, dieselben Übergaben zwischen Beteiligten und die fachlichen Prüfungen, die auch im Produktivsystem benötigt werden.
Während der Probe werden nicht nur Fehler gesammelt. Das Team misst:
- Start- und Endzeit jedes kritischen Schritts,
- Wartezeiten zwischen Teams oder Systemen,
- Dauer der technischen und fachlichen Prüfungen,
- Anzahl und Art manueller Eingriffe,
- Zeit für Fehleranalyse, Korrektur und Wiederanlauf sowie
- Auswirkungen paralleler Aufgaben auf Personen und Systeme.
Ein Lauf, der technisch in drei Stunden endet, kann trotzdem sechs Stunden Cutover-Zeit beanspruchen, wenn Daten erst bereitgestellt, übertragen, bestätigt und fachlich geprüft werden müssen. Deshalb gehören nicht nur Maschinenlaufzeiten, sondern auch Übergabe- und Entscheidungszeiten in den Plan.
Nach der Generalprobe wird der Cutover-Plan aktualisiert. Kritische Pfade erhalten realistische Puffer. Unklare Arbeitsanweisungen werden präzisiert. Aufgaben mit derselben Schlüsselperson werden entzerrt. Wiederholte Handarbeit wird in die Transformationslogik oder das Runbook übernommen. Erst diese Korrekturschleife macht die Probe wertvoll.
Go-/No-go-Kriterien müssen vor dem Wochenende entschieden sein
Unter Zeitdruck werden Abweichungen schnell relativiert: „Nur wenige Fehler“, „wahrscheinlich unkritisch“ oder „korrigieren wir nach dem Go-live“. Solche Aussagen können richtig sein, sind aber ohne vorab festgelegte Kriterien keine belastbare Entscheidungsgrundlage.
Go-/No-go-Kriterien sollten nach geschäftlicher Bedeutung unterscheiden. Beispiele sind:
- alle geschäftskritischen Datenobjekte wurden vollständig geladen,
- definierte Mengen- und Summenabgleiche liegen innerhalb der vereinbarten Toleranz,
- keine offenen Fehler verhindern zentrale Geschäftsprozesse,
- kritische Beziehungen und Schlüssel sind technisch konsistent,
- benannte Fachverantwortliche haben ihre Prüfungen dokumentiert abgeschlossen,
- verbleibende Abweichungen besitzen eine akzeptierte Auswirkung und einen ausführbaren Korrekturweg.
Die Kriterien müssen zum Datenobjekt passen. Ein einzelner fehlerhafter, inaktiver Ansprechpartner ist anders zu bewerten als fehlende Bestände oder offene Aufträge. Deshalb darf die Freigabe nicht allein aus einer globalen Fehleranzahl abgeleitet werden.
Ebenso wichtig ist der letzte sinnvolle Entscheidungspunkt. Vor der Freigabe des neuen Systems kann ein Rückfall auf das Altsystem unter Umständen noch möglich sein. Nach Beginn des produktiven Betriebs entstehen dagegen neue Vorgänge im Zielsystem. Dann ist „zurück“ häufig keine einfache Wiederherstellung mehr, sondern ein eigenes Migrations- und Abstimmungsproblem. Der Plan sollte deshalb zwischen Rückfall vor Betriebsfreigabe und kontrollierter Vorwärtskorrektur nach Betriebsbeginn unterscheiden.
Wer im Cutover wofür verantwortlich sein sollte
Ein ausführbarer Plan braucht mehr als eine allgemeine RACI-Matrix. Für jede kritische Aufgabe müssen Ausführung, Vertretung, Prüfung und Entscheidung konkret besetzt sein.
- Cutover-Leitung: steuert den Gesamtplan, Abhängigkeiten, Statuskommunikation und Eskalation.
- Verantwortung Datenmigration: koordiniert Extraktion, Transformation, Übergaben, Ladefolgen und technische Nachweise.
- Quellsystem-Verantwortliche: bestätigen Datenstopp, Extraktionsbereitschaft und Quellnachweise.
- ERP-Partner oder Zielsystem-Team: stellt produktive Importwege, Konfiguration, Berechtigungen und technische Ladeunterstützung sicher.
- Fachliche Datenverantwortliche: prüfen die vereinbarten Datenobjekte anhand definierter Kriterien.
- Entscheidungsbefugte Projektleitung: trifft Go-/No-go- und Eskalationsentscheidungen auf Basis der Nachweise.
- Betrieb und Support: übernehmen Monitoring, Befunde und Korrekturwege nach der Freigabe.
Gerade die Schnittstelle zwischen ERP-Partner und Kundenteam bleibt häufig unscharf. Der ERP-Partner stellt beispielsweise Importstrukturen und Ladewerkzeuge bereit, während das Unternehmen für Quellauswahl, fachliche Regeln und Datenfreigabe verantwortlich bleibt. Wenn niemand die Arbeit dazwischen führt, entstehen die riskantesten Lücken: nicht reproduzierbare Übergabedateien, ungeklärte Fehlerursachen und fehlende Abstimmung zwischen Quelle und Ziel.
Wann externe Unterstützung vor dem Go-live noch wirksam helfen kann
Ein externer Datenmigrationsdienstleister sollte nicht erst am Cutover-Wochenende hinzugezogen werden. Wirksam wird Unterstützung, wenn noch Zeit besteht, den Ablauf zu analysieren, mindestens einen realistischen Lauf zu begleiten und Korrekturen reproduzierbar umzusetzen.
Ein klar abgrenzbares Arbeitspaket kann beispielsweise umfassen:
- den aktuellen Migrationsstand und die kritischen Lücken bewerten,
- Extraktion und Transformation in einen wiederholbaren Ablauf überführen,
- ein Migrations-Runbook mit Versionen, Prüfungen und Wiederanlauf erstellen,
- Laufzeiten und Abhängigkeiten in einer Generalprobe messen,
- technische Abstimmungen zwischen Quellsystem, ERP-Partner und Fachbereichen führen,
- Quell-, Übergabe- und Zielbestände nachvollziehbar vergleichen sowie
- die Datenmigrationsaufgaben in den Gesamt-Cutover integrieren.
Die fachliche Freigabe und die endgültige Go-/No-go-Entscheidung bleiben beim Unternehmen. Externe Unterstützung sorgt dafür, dass diese Entscheidungen auf einem kontrollierten Ablauf und verständlichen Nachweisen beruhen.
Wenn Sie den Leistungsumfang mehrerer Anbieter einordnen, helfen unsere zwölf Fragen zum Vergleich von Datenmigration-Dienstleistern. Für eine wirtschaftliche Abgrenzung des Arbeitspakets zeigt der Beitrag zu den Kosten einer ERP-Datenmigration, welche Aufwandstreiber vor einem Angebot geklärt werden sollten.
Was Sie für die Klärung des nächsten Schritts bereithalten sollten
Für eine erste belastbare Einschätzung ist noch kein vollständig ausgearbeiteter Cutover-Plan erforderlich. Hilfreich sind der geplante Go-live, die beteiligten Quell- und Zielsysteme, die priorisierten Datenobjekte, der Stand der letzten Testmigration, gemessene oder geschätzte Laufzeiten sowie die aktuell größten technischen und fachlichen Blockaden.
Aus diesen Informationen lässt sich erkennen, ob vor allem der Cutover detailliert werden muss oder ob ein früherer Teil der Datenmigration noch nicht stabil genug ist. Ebenso wird sichtbar, welches Arbeitspaket intern bleiben kann, welche Aufgaben beim ERP-Partner liegen und wo eine externe Übernahme den Go-live konkret entlasten würde.