Eine ERP-Migration ist der Wechsel von einem bisherigen ERP-System oder einer wesentlich anderen Systemversion in eine neue Arbeitsumgebung. Dazu gehören Prozesse, Einstellungen, Schnittstellen, Tests, Schulungen und der produktive Umstieg. Die Datenmigration ist ein eigener Teil dieses Gesamtprojekts: Sie sorgt dafür, dass die künftig benötigten Stamm-, Bestands- und Bewegungsdaten im neuen System vollständig, richtig und nutzbar ankommen.
Diese Unterscheidung ist wichtig, weil in Projektplänen häufig nur eine Zeile „Daten übernehmen“ steht. Hinter dieser Zeile liegen jedoch Entscheidungen, technische Arbeit und mehrere Testläufe. Werden sie zu spät sichtbar, kann aus einem Teilprojekt der kritische Pfad der gesamten ERP-Migration werden.
ERP-Migration und Datenmigration sind nicht dasselbe
Die ERP-Migration verändert die betriebliche Arbeitsumgebung. Das Unternehmen entscheidet, wie Einkauf, Vertrieb, Produktion, Lager, Finanzwesen und weitere Bereiche künftig im neuen System arbeiten. Dafür werden Prozesse gestaltet, Organisationseinheiten eingerichtet, Rollen vergeben und Schnittstellen angebunden.
Die Datenmigration verbindet dagegen die bisherige Informationswelt mit diesem Ziel. Sie klärt beispielsweise, welcher alte Lieferant im neuen System welchem Geschäftspartner entspricht, wie Materialnummern übernommen werden, welche offenen Vorgänge am Stichtag noch gebraucht werden und welche Historie im Altsystem lesbar bleiben kann. Ohne diese Verbindung kann das neue ERP technisch bereitstehen, aber nicht zuverlässig mit den eigenen Geschäftsdaten arbeiten.
Wer zunächst die Grundlagen dieser Teilaufgabe einordnen möchte, findet sie im Beitrag Was ist Datenmigration beim ERP-Wechsel?.
Aus sieben Arbeitssträngen entsteht ein produktives ERP-System
Eine belastbare ERP-Migration besteht nicht aus einer einzigen linearen Aufgabenliste. Mehrere Arbeitsstränge laufen parallel und beeinflussen sich gegenseitig:
- Zielprozesse und Organisation: Das Projekt legt fest, wie künftig gearbeitet wird und welche Werke, Buchungskreise, Lagerorte, Einkaufsorganisationen oder Vertriebsbereiche dafür benötigt werden.
- Konfiguration und Erweiterungen: Das ERP-System wird auf diese Abläufe eingestellt. Notwendige Zusatzentwicklungen werden spezifiziert, umgesetzt und getestet.
- Schnittstellen: Fachanwendungen, Maschinen, Shops, Banken, Dokumentenarchive und andere Systeme müssen zum neuen ERP passen.
- Datenmigration: Benötigte Informationen werden aus den Quellen identifiziert, fachlich zugeordnet, bereinigt, transformiert, geladen und geprüft.
- Prozess- und Integrationstests: Das Team prüft nicht nur einzelne Masken, sondern vollständige Abläufe mit realistischen Daten.
- Rollen, Schulung und Veränderung: Mitarbeitende erhalten Berechtigungen, lernen die neuen Abläufe und bereiten ihre tägliche Arbeit vor.
- Cutover und Stabilisierung: Der Cutover ist der kontrollierte Wechsel in den Produktivbetrieb. Er verbindet letzte Datenläufe, technische Umschaltung, fachliche Freigaben und die Betreuung nach dem Start.
Diese Stränge sind voneinander abhängig. Ein noch veränderter Zielprozess kann neue Pflichtfelder erzeugen. Eine fehlende Schnittstelle beeinflusst möglicherweise, aus welcher Quelle ein Wert künftig kommt. Und ein Integrationstest bleibt wenig aussagekräftig, wenn nur künstliche Beispieldaten statt der späteren Kunden-, Material- oder Auftragsstrukturen verwendet werden.
Welche Rolle spielt die Datenmigration im ERP-Projekt?
Die Datenmigration ist die Übersetzungsarbeit zwischen fachlichem Ziel, alter Datenrealität und technischer Lademöglichkeit. Ein Importwerkzeug löst davon nur den letzten Teil. Es kann vorbereitete Daten prüfen oder laden, entscheidet aber nicht von selbst, welche Informationen gebraucht werden, wo sie im Altsystem liegen und wie unterschiedliche Bedeutungen zusammengeführt werden.
Ein vollständiger Bearbeitungsweg beginnt deshalb am Ziel. Für jedes Datenobjekt wird geklärt, welche Informationen die künftigen Prozesse benötigen. Danach folgen Quellanalyse, Mapping, Transformation, wiederholbarer Export, Testimport und fachliche Prüfung. Mapping bezeichnet dabei die fachliche Zuordnung zwischen Zielanforderung und vorhandener Quelle. Es hält also nicht nur zwei ähnlich benannte Spalten nebeneinander, sondern beschreibt auch Regeln, Konstanten, Wertübersetzungen und offene Entscheidungen.
Wie diese Arbeit über mehrere Testschleifen aufgebaut werden kann, zeigt unser Fahrplan für die Datenmigration im ERP-Projekt.
Drei Entscheidungen bestimmen den tatsächlichen Datenumfang
Der Datenumfang lässt sich nicht zuverlässig aus der Anzahl vorhandener Importdateien ableiten. Entscheidend sind drei Fragen, die aus den künftigen Abläufen beantwortet werden müssen.
1. Welche Daten braucht der erste produktive Tag?
Dazu gehören meist ausgewählte Stammdaten, aktuelle Bestände und noch nicht abgeschlossene Geschäftsvorgänge. Welche Objekte konkret notwendig sind, hängt vom Unternehmen und vom Zielsystem ab. Ein Produktionsbetrieb benötigt andere Beziehungen als ein reiner Dienstleister. Auch innerhalb eines Objekts kann ein Teil zwingend sein, während veraltete oder ungenutzte Informationen bewusst entfallen.
2. Welche laufenden Vorgänge müssen fortgeführt werden?
Offene Bestellungen, Kundenaufträge, Fertigungsaufträge oder Finanzposten sind keine bloßen Tabellenzeilen. Sie besitzen Status, Positionen und Beziehungen zu Stammdaten. Das Projekt muss festlegen, welche Vorgänge vor dem Wechsel abgeschlossen werden, welche im neuen ERP neu angelegt werden und welche tatsächlich migriert werden können.
3. Welche Historie muss verfügbar bleiben?
Nicht jede alte Transaktion muss im neuen System fortgeführt werden. Historische Informationen können je nach Bedarf migriert, in einem Archiv bereitgestellt oder im alten System lesbar gehalten werden. Diese Entscheidung gehört früh in den Umfang, weil eine vollständige Historienübernahme technisch und fachlich etwas anderes ist als die Übernahme aktueller Arbeitsbestände.
Woran erkennt man, dass die Datenmigration zum Projektrisiko wird?
Die Datenmigration wird selten durch einen einzigen spektakulären Fehler kritisch. Häufig zeigen mehrere kleine Befunde, dass der Arbeitsstrang hinter dem übrigen ERP-Projekt zurückbleibt:
- Der Umfang besteht nur aus groben Objektnamen, während Teilmengen und Beziehungen ungeklärt sind.
- Importvorlagen liegen vor, aber die Herkunft und Bedeutung vieler Zielfelder ist noch offen.
- Fachbereiche sollen Daten prüfen, haben jedoch noch keine realistischen Testbestände im Zielsystem gesehen.
- Manuelle Änderungen entstehen direkt in Exportdateien und lassen sich beim nächsten Lauf nicht sicher wiederholen.
- Ein erster Testimport ist geplant, obwohl Mapping, Transformation und Prüfkriterien noch nicht belastbar sind.
- Alter Anbieter, neuer Anbieter und Kundenteam liefern einzelne Beiträge, doch niemand führt sie je Datenobjekt zu einem überprüfbaren Ergebnis zusammen.
Keiner dieser Befunde beweist allein, dass ein Go-live scheitert. Zusammen zeigen sie jedoch, dass die Planung nicht mehr nur auf erledigten Aufgaben beruhen darf. Dann braucht jedes Datenobjekt einen sichtbaren Stand: fachlich abgegrenzt, technisch umsetzbar, wiederholbar erzeugt, importiert und geprüft.
Verantwortung lässt sich teilen, das Ergebnis nicht
Der alte ERP-Anbieter kennt sein System, der neue Implementierungspartner kennt die Zielstrukturen und die Fachbereiche kennen die betrieblichen Bedeutungen. Diese Aufteilung ist sinnvoll. Sie erzeugt aber noch keine fertige Migration, solange die Übergaben zwischen den Beteiligten unklar bleiben.
Wir betrachten die Datenmigration deshalb als verbindenden Projektbereich. Wir können Quellstrukturen analysieren, Mappingvorschläge vorbereiten, wiederholbare Transformationen umsetzen, Testläufe begleiten und offene Entscheidungen so aufbereiten, dass die zuständigen Fachbereiche sie treffen können. Die fachliche Entscheidung und Freigabe bleiben beim Kunden; ebenso ersetzen wir weder die ERP-Projektleitung noch den Implementierungspartner.
Welche Aufgaben sinnvoll bei welcher Rolle liegen, erläutert der Beitrag Verantwortung und Rollen in der ERP-Datenmigration.
So bekommt die ERP-Migration einen realistischen Gesamtplan
Die Datenmigration sollte nicht erst beginnen, wenn das Zielsystem fertig konfiguriert ist. Früh können bereits Datenobjekte abgegrenzt, Quellen untersucht, Verantwortlichkeiten geklärt und erste Mappingfragen vorbereitet werden. Gleichzeitig muss der Plan beweglich bleiben, weil Zielprozesse und Konfiguration während der Einführung weiter reifen.
Ein realistischer Gesamtplan verbindet daher die Meilensteine des ERP-Projekts mit überprüfbaren Migrationsergebnissen. Vor einem Integrationstest ist beispielsweise nicht „Datei erstellt“ entscheidend, sondern ob die benötigten Objekte in einer definierten Version geladen, fachlich prüfbar und für die vorgesehenen Abläufe ausreichend sind. Vor dem Go-live kommen aktuelle Datenstände, letzte Änderungen, Freigaben und der zeitlich geplante Schlusslauf hinzu.
Damit wird die Datenmigration weder zum isolierten Technikthema noch zur unsichtbaren Nebenaufgabe. Sie erhält genau die Rolle, die sie in einer ERP-Migration braucht: einen eigenständigen, eng mit Prozessen, Tests und Cutover verbundenen Arbeitsstrang, dessen Ergebnis am ersten produktiven Tag funktionieren muss.