Datenmigration Checkliste: 15 Schritte zum erfolgreichen ERP-Datenumzug

Es gibt einen Punkt in jedem ERP-Projekt, an dem die Ernüchterung einsetzt. Die Prozesse sind modelliert, das Customizing läuft, die Schulungen sind geplant. Und dann stellt jemand die Frage: Was ist eigentlich mit den Daten? In diesem Moment wird vielen Beteiligten zum ersten Mal bewusst, dass der gesamte Projekterfolg an einer Aufgabe hängt, die bisher kaum Aufmerksamkeit bekommen hat: der Datenmigration.

Die Datenmigration ist der Prozess, bei dem Stammdaten, Bewegungsdaten und historische Bestände aus dem Altsystem in das neue ERP-System überführt werden. Was einfach klingt, ist in der Praxis einer der fehleranfälligsten Bereiche des gesamten Projekts. Felder passen nicht zusammen, Formate weichen ab, Pflichtfelder im neuen System existierten im alten nicht. Hinzu kommt: Die Datenqualität im Altsystem ist fast nie so gut, wie die Fachbereiche glauben.

Diese Checkliste fasst die fünfzehn Schritte zusammen, die eine erfolgreiche ERP-Datenmigration ausmachen. Sie basiert auf den Erfahrungen aus zahlreichen Migrationsprojekten im Mittelstand und strukturiert den Prozess in vier klare Phasen: Vorbereitung, Analyse und Bereinigung, Migration und Test sowie Validierung und Go-Live.

Bevor wir die einzelnen Schritte im Detail betrachten, hier der Gesamtüberblick. Die fünfzehn Schritte gliedern sich in vier Phasen, die aufeinander aufbauen. Jede Phase hat ein klares Ziel und definierte Ergebnisse.

Die Vorbereitungsphase entscheidet darüber, ob die Migration kontrolliert verläuft oder zum Blindflug wird. Hier werden die organisatorischen und inhaltlichen Grundlagen geschaffen, auf denen alle weiteren Schritte aufbauen.

Die Datenmigration braucht einen verantwortlichen Migrationsleiter, der sowohl fachliche als auch technische Zusammenhänge versteht. Dieser koordiniert die Zusammenarbeit zwischen IT, Fachbereichen und dem Systemintegrator. Daneben braucht es fachliche Ansprechpartner aus den betroffenen Abteilungen – Vertrieb, Einkauf, Finanzen, Lager – die ihre Daten kennen und Migrationsentscheidungen treffen können.

Einer der häufigsten Fehler in Migrationsprojekten: Die Verantwortung wird an die IT oder den externen Dienstleister delegiert. Was dabei vergessen wird: Nur die Fachbereiche können entscheiden, welche Daten geschäftsrelevant sind, welche bereinigt und welche archiviert werden sollen. Ohne diese fachliche Steuerung wird die Migration zu einem rein technischen Transfer – mit allen Konsequenzen.

Nicht alle Daten aus dem Altsystem müssen ins neue System. Die Frage, welche Daten migriert werden und welche nicht, ist eine der wichtigsten Entscheidungen im gesamten Migrationsprozess. Stammdaten wie Kunden, Lieferanten und Artikel sind in der Regel Pflicht. Bei Bewegungsdaten – offene Aufträge, Buchungshistorien, Lagerbestände – wird es bereits differenzierter.

Definieren Sie den Scope schriftlich und lassen Sie ihn von den Fachbereichen freigeben. Dabei hilft eine einfache Kategorisierung: Muss migriert werden, sollte migriert werden, wird nicht migriert. Diese Entscheidung spart im weiteren Verlauf erheblichen Aufwand, weil sie den Umfang der Analyse, Bereinigung und Testmigration begrenzt.

In vielen Unternehmen liegen Stammdaten nicht nur im ERP-System. Excel-Listen, Access-Datenbanken, CRM-Systeme, Webshops und branchenspezifische Speziallösungen führen oft eigene Stammdaten – teilweise mit abweichenden Strukturen, Nummernkreisen und Qualitätsstandards. Die Inventarisierung aller relevanten Datenquellen ist die Voraussetzung dafür, dass bei der Migration nichts übersehen wird.

Erstellen Sie eine Quellenmatrix: Welche Daten kommen aus welchem System? Welches System führt im Konfliktfall? Gibt es Redundanzen, die vor der Migration aufgelöst werden müssen? Diese Übersicht wird zum zentralen Steuerungsinstrument für den gesamten Migrationsprozess.

Das Migrationskonzept ist das zentrale Planungsdokument. Es beschreibt den Migrationsprozess von Ende zu Ende: technische Vorgehensweise, zeitlicher Ablauf, Verantwortlichkeiten, Risikobetrachtung und Rückfallstrategie. Ein gutes Migrationskonzept beantwortet die Frage: Was passiert, wenn die Produktivmigration scheitert?

Stimmen Sie das Konzept mit allen Beteiligten ab – Projektleitung, Fachbereiche, IT, Systemintegrator. Jeder muss verstehen, was in welcher Reihenfolge passiert und welche Abhängigkeiten bestehen. Ein undokumentierter Migrationsprozess ist kein Prozess, sondern ein Risiko.

In der zweiten Phase geht es darum, den tatsächlichen Zustand der Daten zu verstehen und die notwendigen Korrekturen systematisch durchzuführen. Diese Phase wird in vielen Projekten übersprungen oder verkürzt – mit gravierenden Folgen für die spätere Migrationsqualität.

Bevor Daten migriert werden, muss ihr tatsächlicher Zustand bekannt sein. Eine strukturierte Datenqualitätsanalyse prüft die relevanten Stammdaten auf Vollständigkeit, Eindeutigkeit, Konsistenz und Aktualität. Das Ergebnis ist ein quantitatives Bild: Wie viele Datensätze haben kritische Mängel? Welche Felder sind am häufigsten betroffen? Wo liegen die größten Risiken?

In der Praxis zeigt sich regelmäßig, dass dreißig bis vierzig Prozent der Stammdaten mindestens ein kritisches Qualitätsproblem aufweisen – fehlende Pflichtfelder, Dubletten, inkonsistente Einheiten oder veraltete Datensätze. Ohne diese Analyse gehen diese Probleme direkt in das neue System über und verursachen dort ein Vielfaches an Bereinigungsaufwand.

Nicht jedes Datenproblem muss vor der Migration gelöst werden. Aber die kritischen Probleme müssen identifiziert und priorisiert sein. Definieren Sie klare Bereinigungsregeln: Welche Datensätze werden korrigiert? Welche werden archiviert? Welche werden nicht migriert? Diese Entscheidungen müssen die Fachbereiche treffen, nicht die IT.

Bewährt hat sich eine Priorisierung nach Schweregrad: Kategorie A umfasst Mängel, die die Migration blockieren, weil Pflichtfelder im neuen System fehlen. Kategorie B sind Mängel, die die Datenqualität beeinträchtigen, aber den Migrationsprozess nicht stoppen. Kategorie C sind Optimierungspotenziale, die auch nach dem Go-Live bearbeitet werden können. Kategorie A muss vor der Migration abgeschlossen sein. Bei Kategorie B entscheidet das Migrationsteam. Kategorie C wird dokumentiert und in den laufenden Betrieb überführt.

Das Feldmapping ist das technisch-fachliche Herzstück der Migration. Es definiert, welches Feld im Altsystem welchem Feld im Neusystem entspricht. Das klingt trivial, ist es aber nicht. Feldnamen ändern sich, Datentypen weichen ab, Pflichtfelder kommen hinzu, Strukturen werden aufgeteilt oder zusammengeführt.

Ein gutes Mapping-Dokument enthält für jede Datenobjektklasse – Kunden, Lieferanten, Artikel, Materialien – eine Feld-für-Feld-Zuordnung mit Angaben zu Datentyp, Pflichtfeld-Status, Transformationslogik und Verantwortlichkeit. Es wird gemeinsam von Fachbereich und Technik erstellt und vor der ersten Testmigration abgestimmt.

Nicht alle Daten können eins zu eins übernommen werden. In vielen Fällen müssen Werte transformiert werden: Nummernkreise werden umgestellt, Einheiten konvertiert, Schlüssel neu vergeben, Klassifizierungen angepasst. Diese Transformationsregeln müssen vor der Migration definiert, dokumentiert und getestet werden.

Jede Transformationsregel muss dokumentiert und mit den Fachbereichen abgestimmt sein. Eine undokumentierte Transformation ist eine potenzielle Fehlerquelle, die bei der Validierung schwer zu identifizieren ist.

In der dritten Phase wird die Migration technisch umgesetzt und durch wiederholte Testläufe validiert. Das Ziel ist nicht, beim ersten Versuch fehlerfrei zu migrieren, sondern systematisch zu lernen, wo die Probleme liegen, und sie vor der Produktivmigration zu lösen.

Je nach Systemlandschaft und Datenvolumen kommen unterschiedliche Werkzeuge zum Einsatz: ETL-Tools für automatisierte Extraktion und Transformation, systemeigene Importschnittstellen, CSV-basierte Ladeprozesse oder spezialisierte Migrationssoftware. Entscheidend ist nicht das Werkzeug, sondern die Frage: Ist der Migrationsprozess automatisierbar und wiederholbar?

Manuelle Migrationen über Copy-Paste oder Einzelimporte mögen bei kleinen Datenmengen funktionieren. Ab einer gewissen Komplexität sind sie fehleranfällig, nicht reproduzierbar und nicht dokumentierbar. Investieren Sie in Automatisierung – sie zahlt sich spätestens bei der zweiten Testmigration aus.

Die erste Testmigration ist der Moment der Wahrheit. Sie zeigt, ob das Mapping funktioniert, ob die Transformationsregeln greifen und ob das neue System die migrierten Daten akzeptiert. Erwarten Sie Fehler. Die erste Testmigration hat nicht den Anspruch, fehlerfrei zu sein. Sie hat den Anspruch, Fehler sichtbar zu machen.

Verwenden Sie echte Produktivdaten – idealerweise einen aktuellen Systemabzug. Testdaten mit idealtypischen Werten verschleiern die Probleme, die bei realen Daten auftreten: Sonderzeichen, fehlende Felder, inkonsistente Formate, unerwartete Feldlängen. Nur mit echten Daten sehen Sie, was im Ernstfall passiert.

Nach jeder Testmigration folgt eine systematische Validierung. Prüfen Sie die migrierten Daten auf Vollständigkeit, Korrektheit und Konsistenz. Stimmen die Stückzahlen? Sind die Verknüpfungen intakt? Funktionieren die abhängigen Prozesse – Preisfindung, Konditionssteuerung, Bestandsbewertung?

Dokumentieren Sie jeden Fehler, seine Ursache und die geplante Korrekturmaßnahme. Führen Sie ein Fehlerprotokoll, das über die Testmigrationen hinweg gepflegt wird. So entsteht ein nachvollziehbarer Qualitätsfortschritt, der gegenüber der Projektleitung und den Fachbereichen kommunizierbar ist.

Die zweite Testmigration validiert die Korrekturen aus dem ersten Durchlauf. Sie zeigt, ob die identifizierten Probleme tatsächlich gelöst sind und ob durch die Korrekturen neue Probleme entstanden sind. Gleichzeitig liefert sie belastbare Daten zum Zeitbedarf: Wie lange dauert die Migration? Gibt es Engpässe bei bestimmten Datenobjektklassen?

In komplexen Migrationsprojekten empfehle ich drei Testmigrationen. Die dritte dient als Generalprobe und simuliert den produktiven Ablauf einschließlich der Reihenfolge, der Zeitplanung und der Rollenverteilung. Was in der Generalprobe nicht funktioniert, wird im Echtbetrieb auch nicht funktionieren.

Die letzte Phase stellt sicher, dass die Produktivmigration unter kontrollierten Bedingungen stattfindet und die migrierten Daten den Qualitätsanforderungen entsprechen. Hier entscheidet sich, ob der Go-Live auf einem soliden Datenfundament steht.

Die Generalprobe ist die letzte Testmigration vor dem Produktivlauf. Sie simuliert den gesamten Migrationsablauf unter realistischen Bedingungen: mit dem finalen Datenstand, in der geplanten Reihenfolge, mit den definierten Verantwortlichkeiten und innerhalb des vorgesehenen Zeitfensters. Die Generalprobe beantwortet eine zentrale Frage: Schaffen wir die Migration im verfügbaren Zeitfenster – und stimmen die Ergebnisse?

Planen Sie die Generalprobe mindestens zwei Wochen vor dem geplanten Go-Live. So bleibt genug Zeit, um letzte Korrekturen umzusetzen, ohne den Go-Live-Termin zu gefährden. Wenn die Generalprobe kritische Mängel zeigt, muss der Go-Live-Termin hinterfragt werden. Ein verschobener Go-Live ist besser als ein Go-Live mit fehlerhaften Daten.

Die Produktivmigration folgt dem getesteten und abgestimmten Ablaufplan. Jeder Schritt hat einen Verantwortlichen, einen definierten Zeitrahmen und klare Erfolgskriterien. Das Altsystem wird zu einem definierten Zeitpunkt eingefroren, die finalen Daten werden extrahiert, transformiert und in das neue System geladen.

Entscheidend ist ein funktionierendes Rückfallszenario. Was passiert, wenn die Migration scheitert? Ab welchem Punkt wird abgebrochen? Wie wird das Altsystem reaktiviert? Diese Fragen müssen vor der Produktivmigration beantwortet und dokumentiert sein. Ein undokumentiertes Rückfallszenario ist kein Rückfallszenario.

Nach der Produktivmigration beginnt die systematische Validierung. Die Fachbereiche prüfen ihre Daten anhand vordefinierter Testfälle: Stimmen die Kundenstammdaten? Sind die offenen Aufträge korrekt übernommen? Passen die Lagerbestände? Funktionieren die Preiskonditionen?

Definieren Sie vor der Migration, welche Prüfungen in welcher Reihenfolge durchgeführt werden und wer die Abnahme erteilt. Eine formale Migrationsabnahme durch die Fachbereiche ist nicht bürokratisch – sie ist die Absicherung dafür, dass die migrierten Daten den geschäftlichen Anforderungen entsprechen. Erst nach der Abnahme sollte der produktive Betrieb im neuen System beginnen.

Selbst mit einer strukturierten Checkliste gibt es Risiken, die immer wieder auftreten. Die folgenden Punkte sind keine theoretischen Szenarien, sondern reale Muster aus Migrationsprojekten im Mittelstand.

Eine Checkliste gibt Struktur. Sie ersetzt aber nicht die fachliche Begleitung und die Erfahrung, die es braucht, um Migrationsentscheidungen im konkreten Kontext richtig zu treffen. Welche Bereinigungsregeln sind angemessen? Wie viele Testmigrationen sind realistisch? Wann muss der Go-Live-Termin hinterfragt werden?

Diese Fragen lassen sich nicht mit einer Vorlage beantworten. Sie erfordern Erfahrung aus vergleichbaren Projekten, ein Verständnis der Systemlandschaft und die Fähigkeit, zwischen fachlichen Anforderungen und technischen Möglichkeiten zu vermitteln.

“Die Checkliste sagt Ihnen, was zu tun ist. Die Erfahrung sagt Ihnen, worauf es dabei ankommt.”

– Stefan Radau, Innovera Consulting

Die Datenmigration ist kein Nebenprojekt und kein rein technischer Vorgang. Sie ist eine zentrale Projektaufgabe, die fachliche Kompetenz, technisches Verständnis und strukturiertes Vorgehen erfordert. Unternehmen, die diese fünfzehn Schritte konsequent durchlaufen, reduzieren ihr Migrationsrisiko erheblich.

Der Schlüssel liegt in der Vorbereitung. Wer früh anfängt, den Scope klar definiert, die Datenqualität ehrlich bewertet und genügend Testmigrationen einplant, schafft die Voraussetzung dafür, dass der Go-Live auf einem soliden Datenfundament steht – nicht auf Hoffnung.

In einem kostenlosen 30-minütigen Erstgespräch besprechen wir gemeinsam, wo die größten Migrationsrisiken in Ihrem ERP-Projekt liegen – und welche Schritte jetzt den größten Hebel haben.

Die Dauer hängt vom Datenvolumen, der Anzahl der Quellsysteme und der Datenqualität ab. Für die Gesamtplanung – von der ersten Bestandsaufnahme bis zur Post-Migration-Validierung – sollten Sie mindestens vier bis sechs Monate einplanen. Die eigentliche Produktivmigration findet typischerweise in einem Wochenende oder einer kurzen Betriebsruhe statt. Der Großteil des Aufwands entfällt auf Vorbereitung, Bereinigung und Testmigration.

Mindestens zwei, idealerweise drei. Die erste Testmigration deckt grundlegende Probleme auf: Feldmappings, Formatfehler, fehlende Daten. Die zweite validiert die Korrekturen und liefert belastbare Daten zum Zeitbedarf. Eine dritte Migration dient als Generalprobe unter produktionsnahen Bedingungen und ist besonders bei großen Datenvolumina oder komplexen Systemlandschaften empfehlenswert.

Die Datenmigration braucht eine zentrale verantwortliche Person – den Migrationsleiter. Diese Person muss sowohl fachliche als auch technische Zusammenhänge verstehen und die Schnittstelle zwischen IT, Fachbereichen und Systemintegrator koordinieren. Die rein technische Durchführung kann beim IT-Team oder beim Dienstleister liegen, aber die fachliche Steuerung und Qualitätsverantwortung muss beim Unternehmen selbst verbleiben.

Quellen: Panorama Consulting ERP Report (2023); Bloor Research, Data Migration – A Closer Look (2022); TDWI Research, Data Quality and the Bottom Line (2022); eigene Projekterfahrung aus ERP-Migrationen im Mittelstand