Video: ERP-Datenmigration: vom Workshop zum Go-Live

Stammdaten sind das langlebige Fundament wie Kunden, Lieferanten, Artikel, Kontenrahmen und Konditionen und müssen vollständig und bereinigt ins neue System übernommen werden, weil alle weiteren Vorgänge darauf aufsetzen. Bewegungsdaten sind operative Vorgänge wie offene Aufträge, Bestellungen und Lagerbewegungen und werden typischerweise nur in ihrer aktuellen Form zum Stichtag synchronisiert, nicht in voller Historie. Transaktions- und Buchhaltungsdaten wie Eröffnungsbilanz, offene Posten und Umsatzsteuer-Salden sind steuerlich besonders sensibel und werden meist unter Beteiligung des Steuerberaters übernommen. Bei historischen Altdaten lohnt die bewusste Entscheidung, ob sie wirklich migriert oder das Altsystem nur lesend archiviert wird.

Die Datenmigration gilt als einer der häufigsten Auslöser für verzögerte oder gescheiterte Go-Live-Termine, weil schlechte Datenqualität oft erst auffällt, wenn die Migration bereits läuft, statt in der Vorbereitung. Branchenanalysen ordnen einen großen Teil der ERP-Probleme der Datenebene zu, also unsauberen, unvollständigen oder nicht abgeglichenen Datensätzen, nicht der Software selbst. Erhebungen zu Migrationsprojekten zeigen außerdem, dass ein erheblicher Anteil das geplante Budget und den Zeitrahmen überschreitet, was den Aufwand zusätzlich unterschätzbar macht. Ein vorgeschalteter Datenanalyse-Workshop mit Vollständigkeits-, Plausibilitäts- und Dublettenprüfung senkt dieses Risiko deutlich, weil Probleme vor und nicht während der produktiven Übernahme sichtbar werden.

In der Praxis hat sich ein mehrstufiges Vorgehen mit typischerweise drei Testmigrationen bewährt, statt sich auf einen einzigen Importlauf zu verlassen. Üblich sind ein technischer Initial-Test, bei dem alle Komponenten und das Feld-Mapping grundsätzlich geprüft werden, ein Pre-Final-Test mit aktuellen Daten rund sechs Wochen vor Go-Live und ein Final-Test ein bis zwei Wochen davor. Viele Teams beginnen bewusst mit kleinen repräsentativen Teilmengen, etwa einigen Dutzend Kunden, Artikeln und Aufträgen, und erweitern den Umfang schrittweise. So werden Fehlerquellen wie fehlende Kundenreferenzen oder inaktive Datensätze früh entdeckt, bevor sie den produktiven Start gefährden.

Steuerlich relevante Daten unterliegen den GoBD und der Abgabenordnung, wobei Bücher, Inventare und Bilanzen zehn Jahre aufzubewahren sind, während für Buchungsbelege und Rechnungen seit dem 4. Bürokratieentlastungsgesetz eine auf acht Jahre verkürzte Frist gilt und sonstige Geschäftskorrespondenz sechs Jahre aufbewahrt werden muss. Die GoBD verlangen, dass aufzeichnungs- und aufbewahrungspflichtige Daten quantitativ und qualitativ gleichwertig ins neue System übernommen werden und über den gesamten Aufbewahrungszeitraum maschinell auswertbar bleiben. Reine Reports oder vorgefilterte Druckdateien genügen nicht, wenn dabei nicht alle aufzubewahrenden Daten erhalten bleiben. Lässt sich eine verlustfreie Migration nicht sicherstellen, muss in der Regel das Altsystem über die Aufbewahrungsfrist erhalten oder revisionssicher archiviert werden, ergänzt um eine dokumentierte Verfahrensdokumentation zum Systemwechsel.

Der Cutover-Plan ist die detaillierte Stunden-Choreografie der eigentlichen Umstellung und legt fest, wann das Altsystem stillgelegt wird, in welcher Reihenfolge Stamm- und Bewegungsdaten übernommen werden und wann die Validierung erfolgt. Bei einem klassischen Wochenend-Cutover wird etwa freitags das Altsystem eingefroren, samstags die Stammdaten- und sonntags die Bewegungsdaten- und Eröffnungsbilanz-Migration mit anschließenden Smoke-Tests durch Key-User durchgeführt, bevor montags der produktive Start erfolgt. Vor dem Go-Live steht immer eine ausdrückliche Go- oder No-Go-Entscheidung auf Basis der Testergebnisse. Ein ausformulierter Roll-Back-Plan ist entscheidend, weil er definiert, bei welcher Eskalation, unter welchen Bedingungen und in welcher Zeit auf das Altsystem zurückgewechselt wird; ohne diese Rückfalloption wird der Cutover zum unkalkulierbaren Risiko.

Für den ETL-Prozess aus Extrahieren, Transformieren und Laden stehen mehrere Ansätze zur Wahl, die sich in Flexibilität und Aufwand unterscheiden. Native ERP-Migrationswerkzeuge wie das SAP Migration Cockpit oder das Data-Migration-Tool von Microsoft Dynamics 365 bieten getestete Standards, sind aber bei komplexen Transformationen weniger flexibel. Allgemeine ETL-Plattformen wie Talend, Pentaho, Apache NiFi oder Microsoft SSIS bieten mehr Spielraum, bringen jedoch eine höhere Lernkurve mit, während reine Custom-Skripte auf Basis von Python oder SQL meist nur für sehr einfache Migrationen sinnvoll sind. Wenn ohnehin eine Integrationsplattform für den laufenden Betrieb vorgesehen ist, können iPaaS-Lösungen wie Boomi oder MuleSoft auch die Migrationsaufgabe mit übernehmen.