Die Dauer einer ERP-Datenmigration lässt sich nicht mit einer allgemeinen Monatszahl seriös beantworten. Dafür werden häufig drei verschiedene Größen miteinander vermischt: die Kalenderzeit des Migrationsprojekts, der tatsächliche Arbeitsaufwand und das enge Zeitfenster für die finale Datenübernahme zum Go-live.
Eine erste Zeitspanne kann trotzdem früh geplant werden. Belastbar wird sie jedoch erst, wenn der Datenumfang, die Abhängigkeiten zum Zielsystem, die Verfügbarkeit der Fachbereiche und mindestens ein vollständiger Weg von der Quelle bis zur fachlichen Prüfung sichtbar sind. Wer vorher eine genaue Laufzeit nennt, beschreibt vor allem Annahmen.
Für ERP-Projektleitungen ist deshalb nicht nur die Frage wichtig, wie lange die Datenmigration dauern könnte. Entscheidend ist, auf welchem Wissensstand die Schätzung beruht und wann sie mit echten Ergebnissen neu berechnet wird.
Zuerst trennen: Projektlaufzeit, Arbeitsaufwand und Cut-over-Fenster
Eine Datenmigration kann viel Arbeitsaufwand enthalten und sich trotzdem über einen noch längeren Kalenderzeitraum ziehen, weil Entscheidungen, Zielkonfigurationen oder Prüfungen fehlen. Umgekehrt kann ein eingespieltes Team zahlreiche Aufgaben parallel bearbeiten, ohne dass sich das produktive Ladefenster automatisch verkürzt. Dieses Cut-over-Fenster bezeichnet die begrenzte Zeitspanne, in der die finalen Daten bereitgestellt, geladen, geprüft und für den Go-live freigegeben werden.
| Zeitangabe | Was sie beschreibt | Wofür sie gebraucht wird |
|---|---|---|
| Kalenderdauer | Die Zeit vom Beginn der Migrationsarbeit bis zur fachlich freigegebenen und stabilisierten Datenübernahme. | ERP-Terminplan, Meilensteine und Go-live-Risiko. |
| Arbeitsaufwand | Die benötigte Leistung für Analyse, Mapping, technische Umsetzung, Tests, Koordination und Dokumentation. | Kapazitäts- und Kostenplanung sowie Abgrenzung interner und externer Aufgaben. |
| Cut-over-Fenster | Die verfügbare Zeit für Datenstopp, finale Extraktion, Transformation, Laden, Prüfung und Freigabe. | Produktivsetzung und Entscheidung, ob der Ablauf praktisch ausführbar ist. |
Diese Trennung verhindert einen häufigen Planungsfehler: Aus der technischen Laufzeit einer Importdatei lässt sich weder die Dauer der Vorbereitung noch der gesamte fachliche Prüfaufwand ableiten. Der bestehende Fahrplan für die Datenmigration beschreibt die notwendigen Phasen und Ergebnisse. Dieser Beitrag konzentriert sich darauf, wie daraus eine belastbare Zeitplanung entsteht.
Eine erste Schätzung braucht fünf konkrete Projektinformationen
Für einen frühen Zeitkorridor müssen noch nicht alle Felder gemappt sein. Fünf Punkte sollten jedoch so konkret vorliegen, dass Unsicherheit sichtbar wird:
| Planungsgrundlage | Welche Frage beantwortet werden muss | Auswirkung auf die Dauer |
|---|---|---|
| Datenumfang | Welche Datenobjekte, Gesellschaften, Standorte, offenen Vorgänge und historischen Bestände werden tatsächlich übernommen? | Jedes Objekt erzeugt eigene Regeln, Abhängigkeiten und Prüfarbeit. |
| Quellzugang | Aus welchen Systemen kommen die Daten, wie werden sie bereitgestellt und wie gut sind Struktur und Qualität bekannt? | Unklare oder schwer zugängliche Quellen verlängern Analyse und Extraktion. |
| Zielreife | Sind Importstrukturen, Pflichtfelder, Nummernkreise, Wertelisten und benötigte Konfigurationen stabil? | Änderungen im Ziel können Mapping, Transformation und Tests erneut auslösen. |
| Entscheidungsfähigkeit | Wer entscheidet fachliche Regeln, und wann stehen diese Personen tatsächlich zur Verfügung? | Offene Entscheidungen erzeugen Wartezeit und blockieren abhängige Arbeit. |
| Test- und Freigabeweg | Welche Nachweise werden verlangt, wer prüft die Daten und welche Korrekturen müssen erneut getestet werden? | Nicht nur der Datenlauf, sondern die gesamte Rückmeldung bis zur Freigabe bestimmt die Kalenderzeit. |
Auch die ERP-Migrationscheckliste von SAP nennt unter anderem Unternehmensgröße, Systemkomplexität und Umfang der zu übertragenden Altdaten als Einflussgrößen auf die Dauer und empfiehlt vor der Schätzung eine Analyse von IT-Landschaft und Datenbeständen. Für die konkrete Projektplanung reicht diese grobe Abhängigkeit aber noch nicht. Erst die Verbindung aus Datenobjekten, Zielanforderungen, Entscheidungen und Prüfweg zeigt, wo die Zeit tatsächlich benötigt wird.
Ein Referenzobjekt macht aus Annahmen einen gemessenen Ablauf
Die erste Schätzung wird wesentlich besser, sobald ein ausreichend repräsentatives Datenobjekt vollständig bearbeitet wurde. Ein Referenzobjekt ist dabei kein besonders einfacher Vorzeigefall, sondern ein Datenbestand, an dem die wesentlichen Arbeitsschritte und Unsicherheiten des Projekts sichtbar werden.
Für dieses Objekt wird die Kette einmal durchlaufen: Quelle analysieren, Zielanforderungen klären, Mapping und Transformationsregeln festlegen, Daten reproduzierbar erzeugen, laden, technisch prüfen und fachlich bewerten. Gemessen wird nicht nur die Bearbeitungszeit. Ebenso wichtig ist die Durchlaufzeit – also die gesamte Kalenderzeit vom Beginn bis zum entscheidungsfähigen Prüfergebnis, einschließlich Wartezeiten und Korrekturen.
Der gemessene Ablauf darf anschließend nicht blind mit der Zahl aller Datenobjekte multipliziert werden. Er zeigt vielmehr, welche Arbeitsschritte im konkreten Projekt anfallen. Danach lassen sich die übrigen Objekte nach Ähnlichkeit, Beziehungen, Sonderregeln und fachlicher Kritikalität gruppieren. Das macht die Schätzung überprüfbar, statt aus einem pauschalen Bauchgefühl eine scheinbar genaue Zahl zu formen.
Vier Zeitblöcke zeigen, wo der Termin wirklich verloren geht
Wir trennen die weitere Planung in vier Zeitblöcke. Dadurch wird erkennbar, welche Arbeit parallel laufen kann und welche Abhängigkeit den Termin weiterhin begrenzt.
Klärungszeit entsteht durch Entscheidungen über den Datenumfang, offene Mapping-Regeln, fehlende Zielwerte und fachliche Ausnahmen. Sie endet nicht mit einem Workshop, sondern erst mit einer Entscheidung, auf der die technische Umsetzung aufbauen kann.
Umsetzungszeit umfasst Extraktion, Transformation, Bereitstellung, Import und technische Fehlerauswertung. Sie lässt sich gut parallelisieren, wenn Quellen, Regeln und Zielstrukturen stabil genug sind. Ohne diese Voraussetzungen produziert zusätzliche Kapazität dagegen häufig nur mehr Zwischenstände.
Prüf- und Korrekturzeit beginnt nach dem Import. Keyuser und Datenverantwortliche müssen Mengen, Werte, Beziehungen und die Nutzbarkeit in Geschäftsprozessen prüfen. Aus Befunden entstehen Korrekturen, die reproduzierbar in einen neuen Lauf einfließen und erneut bewertet werden.
Abhängigkeitszeit entsteht, wenn Testsysteme, Zielkonfigurationen, Schnittstellen, ERP-Partner oder benötigte Fachpersonen erst zu bestimmten Terminen verfügbar sind. Diese Zeit ist im Leistungskatalog eines Dienstleisters leicht zu übersehen, kann aber die Kalenderdauer stärker bestimmen als die technische Bearbeitung.
Die Migrationsplanung von Microsoft verbindet deshalb Datenumfang, Quellen und Ziele, Werkzeuge, Reihenfolge, Abhängigkeiten, Rollen sowie Tätigkeiten vor und nach dem Cut-over. Für den Terminplan folgt daraus: Maßgeblich ist die längste voneinander abhängige Kette bis zur Freigabe, nicht die Summe isolierter Tätigkeitslisten.
Drei Schätzstände sind ehrlicher als eine einzige feste Zahl
Eine belastbare Planung wird nicht einmal erstellt und anschließend verteidigt. Sie wird mit wachsendem Projektwissen präziser. Dafür reichen drei klar bezeichnete Schätzstände:
- Orientierender Zeitkorridor: Er basiert auf Datenobjektliste, Quellsystemen, erkennbarem Zielstand, geplanten Rollen und Testterminen. Zu jeder Zeitspanne gehören die wichtigsten Annahmen und die offenen Risiken.
- Projektprognose nach dem Referenzobjekt: Nun liegen gemessene Durchlaufzeiten, echte Entscheidungswege und erste technische Befunde vor. Die restlichen Objekte können nachvollziehbar gruppiert und der Plan neu berechnet werden.
- Produktives Cut-over-Fenster: Diese Zeitangabe entsteht erst aus einem produktionsnahen Lauf mit realistischer Datenmenge, Aufgabenfolge, Personen, Prüfungen und Freigaben.
Dieser letzte Schritt ist keine Hochrechnung aus einer kleinen Beispieldatei. Microsoft empfiehlt, den Cut-over im Testsystem mit möglichst realistischen Daten, Werkzeugen, Personen und Zeitabläufen zu üben. Auch SAP sieht wiederholte Testübertragungen vor, in die Korrekturen und Verfeinerungen des vorherigen Laufs einfließen. Die gemessene Zeit wird dadurch zum Ergebnis eines erprobten Prozesses.
Ein zu optimistischer Terminplan ist früh erkennbar
Ein Plan ist nicht deshalb belastbar, weil jedes Feld im Kalender gefüllt ist. Diese Signale zeigen, dass die Dauer wahrscheinlich zu knapp angesetzt wurde:
- Alle Datenobjekte erhalten dieselbe Bearbeitungsdauer, obwohl Quellen, Beziehungen und Prüfungen unterschiedlich sind.
- Beratertage werden unmittelbar in Kalenderwochen umgerechnet, ohne Wartezeiten und interne Mitwirkung zu berücksichtigen.
- Testmigrationen stehen als einzelne Termine im Plan, aber fachliche Auswertung, Korrektur und Folgeentscheidung fehlen.
- Der Zielsystemstand verändert sich noch, während Mapping und Transformation bereits als abgeschlossen gelten.
- Die Laufzeit des Produktivlaufs wird aus einer kleinen Datenmenge abgeleitet, ohne den vollständigen Ablauf zu proben.
- Keyuser, Datenverantwortliche und Entscheider sind benannt, besitzen aber keine reservierten Zeitfenster.
Wie viele vollständige oder gezielte Wiederholungen dafür sinnvoll sind, entscheidet nicht eine Standardzahl. Unser Beitrag über Testmigrationen im ERP-Projekt ordnet diese Entscheidung nach den noch offenen Nachweisen. Für die Ausführung im engen Produktivfenster zeigt der ERP-Cutover-Plan, welche Zeiten, Abhängigkeiten und Freigaben aus den Testläufen übernommen werden müssen.
Kann externe Unterstützung die Datenmigration verkürzen?
Externe Unterstützung kann die Kalenderdauer verkürzen, wenn sie eine konkrete operative Lücke schließt. Dazu gehören beispielsweise die Analyse der Quellen, die Vorbereitung von Mapping-Entscheidungen, die technische Umsetzung wiederholbarer Datenläufe, die strukturierte Fehlerauswertung und die Vorbereitung der fachlichen Prüfung. Dadurch sinken vor allem Wartezeiten zwischen den Arbeitsschritten und unnötige Wiederholungen.
Ein Dienstleister kann jedoch weder fehlende fachliche Entscheidungen ersetzen noch Test- und Freigabeschritte beliebig überspringen. Auch ein größeres Team beschleunigt keine Kette, wenn alle Aufgaben auf dieselbe ungeklärte Zielstruktur warten. Eine seriöse Beschleunigung beginnt deshalb mit der Frage, welcher Zeitblock heute den Termin begrenzt und welche Verantwortung dafür sinnvoll übertragen werden kann.
Wir unterstützen die bestehende ERP-Projektleitung dabei, diese Engstelle zu bestimmen und ein abgegrenztes Arbeitspaket daraus zu bilden. Die Leitung des ERP-Gesamtprojekts sowie die fachlichen Entscheidungen und Freigaben bleiben bei den verantwortlichen Stellen im Unternehmen.
Welche Zeitangabe Sie jetzt verlangen sollten
Fragen Sie bei jeder Laufzeitaussage nach vier Dingen: Welcher der drei Schätzstände liegt vor? Welche Annahmen gelten? Welche Ergebnisse wurden bereits gemessen? Und nach welchem nächsten Datenlauf wird die Prognose aktualisiert?
Vor einem Referenzobjekt ist ein transparenter Zeitkorridor glaubwürdiger als ein exaktes Enddatum. Nach dem ersten vollständigen Zyklus sollte eine objektbezogene Projektprognose möglich sein. Vor dem Go-live braucht das Projekt schließlich ein geprobtes Cut-over-Fenster mit gemessenen technischen und fachlichen Zeiten.
Wenn Ihr Terminplan diese Unterschiede heute noch nicht zeigt, lässt sich der nächste Schritt meist klein halten: Datenumfang und Zielstand prüfen, ein aussagekräftiges Referenzobjekt auswählen und dessen Weg bis zur fachlichen Bewertung vollständig messen. Danach lässt sich wesentlich besser entscheiden, ob der geplante Go-live realistisch ist und an welcher Stelle zusätzliche Unterstützung tatsächlich Zeit gewinnt.