Datenmigration
Datenmigration ist die geplante, einmalige Übertragung von Daten aus einem Altsystem in ein neues System – etwa bei einer ERP-Einführung. Dabei werden Stamm- und Bewegungsdaten extrahiert, bereinigt, umgeschlüsselt und in die Struktur des Zielsystems überführt.
Datenmigration ist die planvolle, in der Regel einmalige Übertragung von Daten aus einem Altsystem in ein neues Zielsystem – klassisch beim Wechsel oder der Ersteinführung eines ERP-Systems. Anders als ein laufender Datenaustausch handelt es sich um ein abgeschlossenes Projekt mit definiertem Stichtag: Die Daten werden aus der Altumgebung extrahiert, bereinigt, an das Datenmodell des neuen Systems angepasst (transformiert) und schließlich in dieses geladen. Ziel ist, dass das neue System zum Go-Live mit korrekten, vollständigen und konsistenten Daten arbeitet.
Betroffen sind vor allem die Stammdaten (Artikel, Kunden, Lieferanten, Konten) und je nach Umfang auch offene Posten, Lagerbestände und historische Bewegungsdaten wie Aufträge oder Rechnungen. Weil Altbestände fast immer Dubletten, Tippfehler, Karteileichen und uneinheitliche Formate enthalten, ist die eigentliche Herausforderung selten die technische Übertragung, sondern die vorgelagerte Datenbereinigung und das saubere Mapping der Felder. Eine schlecht vorbereitete Datenmigration verlagert Altlasten nur in ein neues, teureres System – eine gute schafft die Grundlage für verlässliche Prozesse und Auswertungen.
Auf einen Blick
- Einmalige, projekthafte Übertragung von Daten aus Alt- in Zielsystem
- Kernschritte: Extrahieren, Bereinigen, Transformieren/Mappen, Laden, Validieren (ETL)
- Betrifft Stammdaten, offene Posten, Bestände und ggf. historische Belege
- Erfolgsfaktor Nr. 1: Datenqualität – „garbage in, garbage out"
- Abzugrenzen vom laufenden Datenimport/-export und der Schnittstellen-Integration
Wie eine Datenmigration abläuft
Eine Datenmigration folgt üblicherweise dem ETL-Muster: Extract, Transform, Load. Zuerst werden die Daten aus dem Altsystem extrahiert – per Datenbank-Export, API oder standardisiertem CSV/Excel-Auszug. Anschließend werden sie transformiert: bereinigt, dedupliziert, umformatiert und auf die Feld- und Wertestruktur des Zielsystems abgebildet. Erst danach erfolgt das Laden in das neue System, gefolgt von einer Validierung, die prüft, ob Anzahl, Summen und Feldinhalte stimmen.
In der Praxis wird eine Migration nicht in einem Rutsch produktiv gesetzt, sondern iterativ erprobt. Mehrere Testläufe („Testmigrationen" oder „Migrations-Proben") mit echten Daten decken Mapping-Fehler, fehlende Pflichtfelder und Formatprobleme auf, bevor sie den Echtbetrieb erreichen. Kurz vor dem Go-Live wird ein finaler Stichtag festgelegt, zu dem der aktuelle Datenstand – insbesondere offene Posten und Lagerbestände – eingefroren und übernommen wird.
Feld-Mapping und Umschlüsselung
Das Feld-Mapping legt fest, welches Feld im Altsystem welchem Feld im Zielsystem entspricht – etwa „Kundennr." auf „Debitorennummer" oder ein Freitext-Land auf einen genormten ISO-Ländercode. Häufig müssen dabei Werte umgeschlüsselt werden, weil das neue System andere Schlüssel, Nummernkreise oder Pflichtfelder erwartet. Ein sauber dokumentiertes Mapping ist das Herzstück jeder Migration: Es macht Entscheidungen nachvollziehbar und Testläufe reproduzierbar.
Big Bang vs. schrittweise Migration
Beim „Big Bang" wird zu einem Stichtag der gesamte Datenbestand übernommen und das Altsystem abgeschaltet – einfach im Schnitt, aber risikoreicher. Bei der schrittweisen (phasenweisen) Migration laufen Alt- und Neusystem eine Zeit lang parallel, und Datenbereiche werden nacheinander überführt. Das senkt das Risiko, erhöht aber die Komplexität, weil beide Systeme temporär synchron gehalten werden müssen.
Warum Datenqualität über den Erfolg entscheidet
Der Grundsatz „garbage in, garbage out" gilt bei der Datenmigration besonders. Werden fehlerhafte oder doppelte Datensätze ungeprüft übernommen, pflanzen sie sich in jeden Beleg fort, der später darauf verweist – und untergraben von Beginn an das Vertrauen der Anwender in das neue System. Deshalb gehört die Datenbereinigung fachlich vor die technische Übertragung: Dubletten zusammenführen, Karteileichen aussortieren, Formate vereinheitlichen und fehlende Pflichtangaben ergänzen.
Bewährt hat sich, die Datenqualität früh zu messen und Verantwortliche aus den Fachabteilungen einzubinden, denn nur sie können beurteilen, ob ein Datensatz noch benötigt wird oder ein Wert korrekt ist. Typische Prüfpunkte sind Vollständigkeit von Pflichtfeldern, Eindeutigkeit von Nummern, Gültigkeit von Formaten (etwa IBAN, USt-IdNr. oder Postleitzahl) und die Auflösung von Dubletten zu einem eindeutigen Datensatz. Häufig wird die Migration bewusst genutzt, um Altbestände zu entrümpeln – etwa inaktive Artikel oder Kunden ohne Umsatz nicht mitzunehmen. Weniger, aber saubere Daten sind fast immer wertvoller als ein vollständiger, aber verschmutzter Altbestand.
Datenmigration im ERP-Projekt
Bei einer ERP-Einführung ist die Datenmigration regelmäßig der aufwendigste und heikelste Teilbereich – und ein häufiger Grund für verschobene Go-Live-Termine. Sie sollte daher als eigenständiges Teilprojekt mit eigenem Zeitplan, Zuständigkeiten und Testkonzept geführt werden, nicht als Nebenaufgabe der Software-Einführung. Umfang und Zieldefinition gehören idealerweise ins Lastenheft bzw. Pflichtenheft, damit klar ist, welche Daten in welcher Tiefe übernommen werden.
Eine zentrale Entscheidung ist der Umgang mit Historie: Müssen zehn Jahre Rechnungshistorie ins neue System, oder genügt es, offene Posten und aktuelle Stammdaten zu migrieren und das Altsystem für Nachweiszwecke revisionssicher zu archivieren? Oft ist Letzteres günstiger und aus GoBD-Sicht ausreichend, sofern die aufbewahrungspflichtigen Daten im Altsystem oder Archiv unveränderbar verfügbar bleiben.
Abgrenzung: Migration vs. Import/Export vs. Integration
Datenmigration ist ein einmaliger, projekthafter Vorgang mit Stichtag. Der Datenimport/-export bezeichnet dagegen wiederkehrende Massen-Übernahmen im laufenden Betrieb – etwa den regelmäßigen Import einer Preisliste. Die Integration wiederum ist der dauerhafte, oft automatisierte Datenaustausch zwischen produktiven Systemen über APIs oder Schnittstellen, etwa zwischen ERP und Onlineshop. Migration ist also die einmalige Überführung, Integration der laufende Abgleich.
Typische Risiken und wie man sie beherrscht
Die häufigsten Fehler sind unterschätzte Datenmengen, unklare Verantwortlichkeiten für die Bereinigung, fehlende oder zu späte Testläufe und ein Mapping, das fachlich nicht abgestimmt wurde. Besonders tückisch sind semantische Unterschiede: Wenn ein Feld im Altsystem etwas anderes bedeutet als im Zielsystem, führt ein rein technisch korrektes Mapping trotzdem zu falschen Ergebnissen.
Beherrschbar wird das Risiko durch ein wiederholbares Vorgehen: dokumentiertes Mapping, mehrere Testmigrationen mit Echtdaten, definierte Abnahmekriterien (Datensatzzahlen, Kontrollsummen, Stichproben) und ein Rollback-Plan für den Fall, dass der finale Ladelauf scheitert. Ebenso wichtig ist ein realistischer Zeitpuffer rund um den Stichtag, weil die finale Übernahme oft in einem engen Wartungsfenster erfolgen muss, in dem das Tagesgeschäft ruht. Wer diese Punkte diszipliniert abarbeitet, verwandelt die vermeintlich riskante Datenmigration in einen planbaren, reproduzierbaren Schritt – und legt damit das Fundament für einen reibungslosen Go-Live.
Praxisbeispiel
Beispiel: ERP-Wechsel bei einem Multichannel-Händler
Ein Händler mit rund 12.000 Artikeln und Verkäufen über eigenen Shop und Marktplätze wechselte von einer gewachsenen Insellösung auf ein integriertes ERP. Der Altbestand enthielt zahlreiche Dubletten im Kundenstamm, inaktive Artikel und uneinheitliche Ländercodes. Statt alles zu übernehmen, definierte das Team im Vorprojekt klare Regeln: Kunden ohne Umsatz der letzten drei Jahre entfielen, Artikel wurden auf eindeutige Nummern normiert, Länder auf ISO-Codes gemappt.
In drei Testmigrationen wurden Mapping-Fehler und fehlende Pflichtfelder aufgedeckt und korrigiert. Zum Stichtag am Monatsende wurden nur aktuelle Stammdaten, offene Posten und Lagerbestände produktiv geladen; die vollständige Beleghistorie blieb revisionssicher im archivierten Altsystem. Ergebnis: ein Go-Live mit sauberen Daten, verlässliche Bestände am ersten Tag und ein deutlich kleinerer, dafür korrekter Datenbestand – der Aufwand steckte fast vollständig in Bereinigung und Mapping, nicht im eigentlichen Ladevorgang.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Quellen
Fragen zu Datenmigration in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.