Datenmigration bedeutet, die benötigten Informationen aus einem alten System auszuwählen, für ein neues System aufzubereiten, zu übertragen und anschließend zu prüfen. Bei einem ERP-Wechsel sollen die Daten also nicht nur an einem anderen Speicherort liegen. Kunden, Materialien, offene Aufträge oder Bestände müssen im neuen ERP-System vollständig, richtig miteinander verbunden und für die vorgesehenen Geschäftsprozesse nutzbar sein.
Genau darin unterscheidet sich eine Datenmigration vom bloßen Kopieren einer Datenbank. Das alte und das neue ERP-System speichern dieselbe fachliche Information häufig in unterschiedlichen Strukturen. Deshalb muss das Projekt klären, welche Daten gebraucht werden, was sie im Altsystem bedeuten und nach welchen Regeln sie im Zielsystem ankommen sollen.
Ein ERP-Wechsel macht diesen Unterschied besonders sichtbar. Das neue System übernimmt nicht automatisch die gewachsene Logik des alten. Die Datenmigration baut deshalb eine kontrollierte Brücke zwischen beiden Systemen.
Datenmigration beginnt mit einer Auswahl, nicht mit dem Export
Bevor die erste Datei erzeugt wird, braucht das Projekt eine fachliche Entscheidung: Mit welchen Daten soll das neue ERP-System am ersten produktiven Tag arbeiten? Dabei geht es nicht darum, vorsorglich alles zu übernehmen. Veraltete Stammsätze, abgeschlossene Vorgänge oder jahrelange Historien können den Aufwand erhöhen, ohne im neuen System einen operativen Nutzen zu haben.
Die Auswahl wird üblicherweise nach Datenobjekten getroffen. Ein Datenobjekt fasst Informationen zusammen, die fachlich gemeinsam betrachtet und migriert werden, etwa Kunden, Lieferanten, Materialien, offene Aufträge oder Lagerbestände. Für jedes dieser Objekte muss entschieden werden, welche Datensätze ins neue ERP gehören, welche nur im Archiv erreichbar bleiben und welche nicht mehr benötigt werden.
Diese Entscheidung beeinflusst alle folgenden Schritte. Sie bestimmt, welche Quellen analysiert, welche Regeln erstellt und welche Ergebnisse später geprüft werden müssen. Eine ausführliche Entscheidungshilfe dazu bietet unser Beitrag Datenmigration beim ERP-Wechsel: Welche Daten gehören ins neue System?
Ein offener Kundenauftrag zeigt den vollständigen Datenweg
Ein offener Kundenauftrag eignet sich gut, um den Ablauf zu verstehen. Im alten ERP erscheint er für den Anwender als zusammengehörender Vorgang. Technisch verweist er jedoch unter anderem auf einen Kunden, mehrere Artikel, Mengen, Preise, Lieferbedingungen und einen Bearbeitungsstatus. Damit der Auftrag im neuen ERP nutzbar ist, müssen auch die benötigten Stammdaten und Beziehungen vorhanden sein.
Die Migration dieses Auftrags ist deshalb keine einzelne Dateiübertragung. Sie besteht aus mehreren Schritten, die logisch aufeinander aufbauen.
Die benötigten Informationen im Altsystem finden
Zuerst wird geklärt, wo die relevanten Werte tatsächlich gespeichert sind. Ein Feld auf der alten Benutzeroberfläche muss nicht aus einer einzigen Datenbankspalte stammen. Werte können verteilt, miteinander verknüpft oder aus mehreren Angaben abgeleitet sein. Die technische Analyse muss diese Herkunft sichtbar machen, bevor eine belastbare Übertragungsregel entstehen kann.
Die alte Bedeutung in die neue Struktur übersetzen
Danach wird festgelegt, wie jedes benötigte Merkmal im Zielsystem abgebildet wird. Diese Übersetzung heißt Datenmapping: Für einen Wert wird beschrieben, aus welcher Quelle er kommt, in welches Zielfeld er gehört und ob er vorher verändert werden muss.
Beim Kundenauftrag kann beispielsweise ein alter Status nicht unverändert übernommen werden, weil das neue ERP andere Statuswerte oder Prozessschritte verwendet. Dann braucht das Projekt eine fachlich bestätigte Regel. Dasselbe gilt für Nummernkreise, Einheiten, Länderkennzeichen, Zahlungsbedingungen oder Beziehungen zwischen Auftragskopf und Positionen. Wie solche Regeln belastbar werden, erläutern wir im Beitrag Datenmapping im ERP-Projekt.
Die Daten für den Import aufbereiten
Die bestätigten Regeln werden anschließend technisch umgesetzt. Dabei können Werte bereinigt, Formate vereinheitlicht, Felder zusammengeführt oder Zielwerte aus mehreren Quellangaben gebildet werden. Dieser Schritt wird Transformation genannt, weil nicht nur der Speicherort, sondern bei Bedarf auch Struktur und Darstellung der Daten verändert werden.
Das Ergebnis ist eine reproduzierbare Importdatei oder ein entsprechend vorbereiteter Datenbestand. Wir setzen dafür bei geeigneten relationalen Altsystemen bevorzugt nachvollziehbare SQL-Skripte ein. Die Beladung selbst erfolgt anschließend über das vom neuen ERP vorgesehene Importwerkzeug. Entscheidend ist nicht ein bestimmtes Werkzeug, sondern dass jede Regel sichtbar, wiederholbar und prüfbar bleibt.
Den Datenweg vor dem Go-live erproben
Eine Testmigration ist eine probeweise Datenübernahme vor dem produktiven Wechsel. Sie zeigt nicht nur, ob eine Datei technisch geladen werden kann. Erst mit echten Testdaten wird sichtbar, ob Pflichtfelder fehlen, Zuordnungen falsch sind oder Abhängigkeiten zwischen Kunden, Materialien und Aufträgen noch nicht funktionieren.
Die gefundenen Fehler führen zurück zur jeweiligen Auswahl-, Mapping- oder Transformationsregel. Nach der Korrektur wird der Ablauf wiederholt. Auf diese Weise entsteht schrittweise ein belastbarer Datenweg, statt erst beim Go-live auf die erste vollständige Übernahme zu hoffen.
Das Ergebnis technisch und fachlich prüfen
Nach dem Import wird zunächst zwischen Quelle, Export und Zielsystem abgeglichen: Sind die vereinbarten Datensätze vollständig angekommen? Wurden Werte nach den festgelegten Regeln umgewandelt? Bestehen die notwendigen Beziehungen?
Danach prüfen die zuständigen Fachbereiche, ob die Daten im neuen ERP tatsächlich verwendbar sind. Ein offener Auftrag kann technisch vorhanden sein und trotzdem fachlich unbrauchbar bleiben, wenn etwa ein falscher Status, eine fehlende Lieferadresse oder eine ungültige Materialzuordnung den weiteren Prozess verhindert. Warum ein erfolgreicher Import allein nicht genügt, zeigt unser Beitrag zur Datenvalidierung bei der ERP-Migration.
Warum Kopieren nicht dasselbe wie Migrieren ist
Beim Kopieren wird ein vorhandener Datenbestand möglichst unverändert an einen anderen Ort übertragen. Das kann sinnvoll sein, wenn Quelle und Ziel dieselbe Struktur und dieselbe Logik verwenden. Bei einem ERP-Wechsel ist genau das meist nicht der Fall.
| Bloßes Kopieren | Datenmigration beim ERP-Wechsel |
|---|---|
| überträgt vorhandene Daten möglichst unverändert | wählt den benötigten Datenbestand bewusst aus |
| setzt eine passende Zielstruktur voraus | übersetzt zwischen unterschiedlicher Quell- und Zielstruktur |
| transportiert auch vorhandene Fehler und Dubletten | wendet vereinbarte Bereinigungs- und Transformationsregeln an |
| ist beendet, wenn die Übertragung technisch abgeschlossen ist | ist erst belastbar, wenn das Ergebnis technisch und fachlich geprüft wurde |
Die eigentliche Arbeit liegt damit nicht im Transport. Sie liegt im Verständnis der Altdaten, in der Übersetzung zur Zielstruktur und im Nachweis, dass das neue ERP mit dem Ergebnis arbeiten kann.
Datenmigration ist nur ein Teil des ERP-Wechsels
Eine ERP-Migration umfasst den gesamten Wechsel auf das neue System. Dazu gehören beispielsweise Prozessgestaltung, Konfiguration, Schnittstellen, Schulungen, Tests und die Inbetriebnahme. Die Datenmigration ist der Teil dieses Vorhabens, der die benötigten Informationen aus den bisherigen Systemen in die neue ERP-Logik überführt.
Auch eine Archivierung verfolgt ein anderes Ziel. Archivierte Daten sollen weiterhin auffindbar oder nachweispflichtig verfügbar bleiben, müssen aber nicht im täglichen Prozess des neuen ERP verarbeitet werden. Eine alte Rechnung kann deshalb im Archiv richtig aufgehoben sein, während ein noch offener Kundenauftrag operativ migriert werden muss.
Diese Abgrenzung verhindert zwei häufige Missverständnisse: Weder muss jede historische Information ins neue ERP übernommen werden, noch ist die gesamte ERP-Einführung erledigt, sobald Daten geladen wurden.
Wann ist die Datenmigration abgeschlossen?
Eine Datenmigration ist nicht schon dann abgeschlossen, wenn das Importprogramm keine Fehlermeldung mehr zeigt. Für einen freigegebenen Datenbestand müssen mehrere Aussagen zusammenpassen:
- Der vereinbarte Datenumfang wurde vollständig verarbeitet.
- Mapping und Transformation entsprechen den bestätigten Regeln.
- Schlüssel, Referenzen und Beziehungen funktionieren im Zielsystem.
- Die Fachbereiche können die vorgesehenen Geschäftsprozesse mit den migrierten Daten ausführen.
Diese Nachweise beziehen sich immer auf einen bezeichneten Datenstand und eine konkrete Regelversion. Werden danach Daten oder Regeln verändert, muss geprüft werden, welche Tests erneut erforderlich sind. So bleibt nachvollziehbar, was tatsächlich freigegeben wurde.
Was diese Erklärung für die frühe Projektplanung verändert
Wer Datenmigration als kontrollierte Übersetzung statt als Dateitransport versteht, stellt schon zu Beginn andere Fragen: Welche Informationen braucht das neue ERP zum Go-live wirklich? Wer verbindet die Bedeutung im Altsystem mit den Anforderungen des Zielsystems? Und anhand welcher Prüfungen wird die Übernahme freigegeben?
Aus diesen drei Fragen entstehen Datenumfang, Mapping, technische Umsetzung und Teststrategie. Fehlt für eine davon eine klare Verantwortung, bleibt die Datenmigration trotz vorhandener Importvorlagen unvollständig geplant. Unser Fahrplan für die Datenmigration im ERP-Projekt zeigt, wie diese Bestandteile bis zum Go-live aufeinander aufbauen.
Wir verstehen Datenmigration deshalb als durchgängige Verbindung zwischen Altsystem, neuem ERP, Fachbereichen und technischer Umsetzung. Externe Unterstützung ist besonders dann sinnvoll, wenn diese Übersetzungsarbeit im Projekt noch niemand vollständig übernimmt. Die fachlichen Entscheidungen und Freigaben bleiben dabei im Unternehmen; wir bereiten sie vor, setzen die vereinbarten Regeln technisch um und machen die Ergebnisse prüfbar.