ERP-Datenmigration: 15 Punkte, die vor dem Go-Live geprüft werden müssen
Die meisten Migrationsprobleme am Go-Live-Tag sind keine technischen Überraschungen – sondern das Ergebnis fehlender Prüfungen in den Wochen davor. Diese Checkliste verhindert, dass Ihr ERP-Projekt am eigenen Datenbestand scheitert.
Datenmigration: Das am meisten unterschätzte Risiko im ERP-Projekt
Es gibt eine Phase in jedem ERP-Projekt, in der alle Beteiligten gleichzeitig nervös werden: die Datenmigration kurz vor dem Go-Live. Prozesse sind modelliert, das Customizing steht, Key-User sind geschult – und dann wird klar, dass die Datenübernahme noch nicht dort ist, wo sie sein müsste. Felder fehlen, Formate stimmen nicht, Dubletten tauchen auf, und die historischen Bestände passen nicht ins neue Datenmodell.
Die Ursache ist fast immer dieselbe: Das Thema Datenmigration wurde zu spät ernst genommen. Teams verlassen sich auf Export-Import-Routinen, die auf dem Papier funktionieren, aber in der Praxis an tausend Kleinigkeiten scheitern. Eine fehlende Postleitzahl in der Adresse. Ein Artikelstamm ohne gültige Mengeneinheit. Ein offener Auftrag, der auf einen Kunden verweist, der im neuen System nicht existiert.
Diese Checkliste fasst die 15 Prüfpunkte zusammen, die vor jedem ERP-Go-Live systematisch abgearbeitet werden müssen. Sie deckt fünf Bereiche ab: Stammdaten, Bewegungsdaten, Datenqualität, Testmigration und Go-Live Readiness. Jeder Punkt enthält konkrete, abprüfbare Kriterien – keine theoretischen Empfehlungen, sondern das, was in realen Projekten den Unterschied gemacht hat.
Datenmigration in Zahlen
0 %
mit Datenqualitätsproblemen
Anteil der ERP-Projekte, die während der Migration auf unerwartete Datenqualitätsprobleme stoßen
0 –5
Testmigrationen empfohlen
Mindestanzahl vollständiger Testmigrationen, bevor der produktive Go-Live verantwortbar ist
0 %
des Projektaufwands
Typischer Anteil der Datenmigration am gesamten ERP-Projektbudget – häufig erst spät eingeplant
0 ×
teurer nach Go-Live
Nachträgliche Datenkorrektur im Produktivbetrieb kostet ein Vielfaches der vorgelagerten Bereinigung
Die 5 Bereiche der Go-Live-Prüfung
Stammdaten
Kunden, Artikel und Lieferanten: die Grundpfeiler jeder Migration. Fehler hier wirken sich auf alle nachgelagerten Prozesse aus.
Bewegungsdaten
Offene Aufträge, Lagerbestände und Finanzdaten müssen zum Stichtag konsistent und vollständig übernommen werden.
Datenqualität
Dubletten, fehlende Pflichtfelder und inkonsistente Referenzen müssen vor dem Go-Live erkannt und bereinigt sein.
Testmigration
Nur wer mehrfach migriert und validiert hat, kann sicher sein, dass der produktive Lauf funktioniert.
Go-Live Readiness
Cutover-Zeitplan, Verantwortlichkeiten und Abnahmekriterien müssen stehen, bevor der Schalter umgelegt wird.
Stammdaten: Fundament der Migration
Stammdaten sind die Referenzdaten, auf die alle Geschäftsprozesse zugreifen. Wenn ein Kundenstamm unvollständig ist, kann kein Auftrag sauber angelegt werden. Wenn ein Artikelstamm fehlerhaft ist, funktioniert weder Einkauf noch Disposition. Stammdaten müssen nicht nur migriert, sondern vor der Migration bereinigt und validiert werden.
Punkt 1: Kundenstammdaten vollständig und konsistent
Der Kundenstamm ist in den meisten Unternehmen der am häufigsten geänderte und gleichzeitig am wenigsten gepflegte Datenbestand. Über Jahre hinweg werden Datensätze angelegt, aber selten bereinigt. Vor dem Go-Live muss jeder einzelne Kundenstammsatz gegen die Anforderungen des neuen Systems geprüft werden.
- Alle Pflichtfelder des Zielsystems sind gefüllt (Name, Adresse, Zahlungsbedingungen, Steuerkennzeichen)
- Kundennummern-Mapping zwischen Alt- und Neusystem ist dokumentiert und abgestimmt
- Ansprechpartner und Kontaktdaten sind aktuell und dem richtigen Kundenstamm zugeordnet
- Adressdaten sind postalisch validiert – insbesondere PLZ, Ort und Länderkennzeichen
- Kreditlimits und Zahlungskonditionen sind vom Vertrieb freigegeben
- Inaktive Kunden sind markiert und eine Entscheidung über Migration oder Archivierung ist getroffen
Punkt 2: Artikelstammdaten strukturiert und vollständig
Der Artikelstamm ist in produzierenden Unternehmen häufig der umfangreichste und komplexeste Datenbestand. Neben Basisdaten wie Bezeichnung und Mengeneinheit gehören dazu oft dutzende zusätzliche Attribute: Gewichte, Abmessungen, Zolltarifnummern, Gefahrgutklassen, Dispositionsparameter. Jeder fehlende Wert kann später zu Prozessabbrüchen führen.
- Artikelnummern-Mapping ist erstellt und eindeutig – keine doppelten Zuordnungen
- Mengeneinheiten sind im Zielsystem hinterlegt und korrekt zugeordnet
- Artikelgruppen und Warengruppen sind im neuen System angelegt und gemappt
- Dispositionsrelevante Daten (Mindestbestand, Beschaffungsart, Wiederbeschaffungszeit) sind geprüft
- Stücklisten und Rezepturen sind vollständig und verweisen nur auf existierende Artikel
- Preislisten und Konditionen sind aktuell und den richtigen Artikeln zugeordnet
- Varianten und Konfigurationen sind im Zielsystem abbildbar
Punkt 3: Lieferantenstammdaten geprüft und freigegeben
Lieferantenstammdaten werden häufig stiefmütterlich behandelt, weil sie weniger Datensätze umfassen als Kunden oder Artikel. Aber ein fehlerhafter Lieferantenstamm kann den gesamten Einkaufsprozess lahmlegen: falsche Bankverbindungen führen zu Zahlungsfehlern, fehlende Ansprechpartner zu Bestellverzögerungen.
- Bankverbindungen sind aktuell und durch den Einkauf oder die Buchhaltung verifiziert
- Steuernummern und Umsatzsteuer-IDs sind gültig und im Zielsystem hinterlegt
- Lieferkonditionen (Incoterms, Zahlungsziele, Mindestbestellwerte) sind abgestimmt
- Lieferanten-Artikel-Zuordnungen (Infosätze) sind vollständig migriert
- Ansprechpartner und Bestelladressen sind aktuell
- Inaktive Lieferanten sind identifiziert und eine Migrationsentscheidung ist dokumentiert
Bewegungsdaten: Was am Stichtag stimmen muss
Bewegungsdaten sind die Daten, die sich täglich ändern: offene Aufträge, Lagerbestände, Salden. Sie zum Stichtag korrekt zu übernehmen, ist die größte logistische Herausforderung der Migration. Jede Stunde Verzögerung erhöht das Risiko von Inkonsistenzen.
Punkt 4: Offene Aufträge und Bestellungen
Offene Aufträge sind der neuralgische Punkt jeder Migration. Sie müssen zum Stichtag exakt den Zustand abbilden, der im Altsystem besteht – einschließlich Teillieferungen, Rückstände und zugesagter Termine. Fehler hier führen zu doppelten Lieferungen, verlorenen Bestellungen oder falschen Rechnungen.
- Vollständige Liste aller offenen Kundenaufträge mit Status, Mengen und Terminen ist exportiert
- Teilgelieferte Aufträge sind mit korrekten Restmengen erfasst
- Offene Bestellungen an Lieferanten sind mit Lieferterminen und Restmengen dokumentiert
- Rahmenverträge und Abrufaufträge sind identifiziert und die Übernahmelogik ist definiert
- Alle referenzierten Kunden, Artikel und Lieferanten existieren im Zielsystem
- Auftragshistorie: Entscheidung ist getroffen, welche abgeschlossenen Aufträge migriert werden
Punkt 5: Lagerbestände und Bestandsführung
Der Lagerbestand muss zum Stichtag auf den Artikel genau stimmen. Ein falsch übernommener Bestand bedeutet entweder Fehlbestände, die zu Produktionsunterbrechungen führen, oder Geisterbestände, die Kapital binden und Disponenten in die Irre führen.
- Inventur oder Bestandsabgleich ist vor dem Migrationsstichtag durchgeführt
- Bestandswerte (Menge und Bewertung) sind je Artikel und Lagerort abgestimmt
- Chargen- und Seriennummern sind vollständig und korrekt zugeordnet
- Sperrbestände, Qualitätsprüfbestände und reservierte Mengen sind separat ausgewiesen
- Lagerorte und Lagerplätze sind im Zielsystem angelegt und gemappt
- Konsignationsbestände bei Kunden und Lieferanten sind berücksichtigt
Punkt 6: Finanzdaten und offene Posten
Die Migration von Finanzdaten erfordert die engste Abstimmung mit der Buchhaltung. Offene Posten, Salden und Steuerinformationen müssen centgenau übereinstimmen. Fehler in diesem Bereich haben direkte rechtliche und finanzielle Konsequenzen.
- Offene Debitoren- und Kreditorenposten sind vollständig mit Belegnummer, Betrag und Fälligkeit exportiert
- Sachkonten-Mapping zwischen altem und neuem Kontenplan ist erstellt und von der Buchhaltung freigegeben
- Eröffnungsbilanz-Werte sind abgestimmt und durch Wirtschaftsprüfer oder Steuerberater validiert
- Steuerrelevante Einstellungen (Steuerkennzeichen, Steuergebiete) sind im Zielsystem korrekt konfiguriert
- Anlagenspiegel ist vollständig mit Anschaffungswerten, Abschreibungen und Restbuchwerten
- Offene Rechnungen und Gutschriften sind mit den zugehörigen Aufträgen verknüpft
Datenqualität: Was die Migration zum Scheitern bringt
Die häufigste Ursache für Migrationsabbrüche sind keine technischen Fehler, sondern Datenqualitätsprobleme. Dubletten, fehlende Pflichtfelder und inkonsistente Referenzen werden oft erst bei der Migration sichtbar – wenn die Korrektur am teuersten ist.
Punkt 7: Dublettenprüfung über alle Stammdaten
Dubletten sind in Altsystemen die Regel, nicht die Ausnahme. Ein Kunde, der unter drei verschiedenen Schreibweisen existiert, erzeugt im neuen System drei Kreditlimits, drei Zahlungshistorien und drei Ansprechpartner-Listen. Vor der Migration müssen Dubletten systematisch identifiziert und zusammengeführt werden.
- Dublettenanalyse für Kundenstamm ist durchgeführt (Name, Adresse, Steuernummer als Matching-Kriterien)
- Dublettenanalyse für Lieferantenstamm ist durchgeführt
- Dublettenanalyse für Artikelstamm ist durchgeführt (Bezeichnung, EAN, Herstellernummer)
- Für jede Dublette ist eine Zusammenführungsstrategie definiert: Welcher Datensatz führt, welcher wird archiviert?
- Zusammengeführte Sätze sind vom Fachbereich bestätigt
- Referenzen auf zusammengeführte Sätze (Aufträge, Rechnungen) sind angepasst
Punkt 8: Feldvalidierung und Pflichtfeldprüfung
Jedes Zielsystem hat eigene Pflichtfeldanforderungen. Was im Altsystem optional war, kann im neuen System verpflichtend sein. Ein klassisches Beispiel: E-Mail-Adressen für den elektronischen Rechnungsversand. Oder Gewichtsangaben für die Versandabwicklung. Jedes fehlende Pflichtfeld führt bei der Migration zu einem Abbruch oder einem Datensatz mit Dummy-Werten – beides inakzeptabel.
- Pflichtfeld-Mapping ist erstellt: Welche Felder sind im Zielsystem obligatorisch?
- Gap-Analyse ist durchgeführt: Welche Pflichtfelder sind in den Quelldaten nicht befüllt?
- Formatvalidierung für alle Felder mit definierten Formaten (PLZ, Telefon, E-Mail, IBAN, USt-ID)
- Wertebereiche sind geprüft: Numerische Felder enthalten keine negativen Werte, wo nur positive erlaubt sind
- Zeichensatzprobleme sind identifiziert (Umlaute, Sonderzeichen, Längenrestriktionen)
- Defaultwerte für nicht befüllbare Felder sind definiert und dokumentiert
Punkt 9: Datenkonsistenz und referenzielle Integrität
Referenzielle Integrität bedeutet: Jeder Verweis in den Daten zeigt auf einen existierenden Datensatz. Ein Auftrag verweist auf einen Kunden – dieser Kunde muss existieren. Ein Stücklisten-Eintrag verweist auf einen Artikel – dieser Artikel muss migriert sein. Verletzte Referenzen führen zu Laufzeitfehlern, die im Produktivbetrieb schwer zu diagnostizieren sind.
- Alle Fremdschlüssel-Beziehungen sind dokumentiert und getestet
- Aufträge verweisen nur auf existierende Kunden, Artikel und Lieferanten im Zielsystem
- Stücklisten verweisen nur auf existierende Komponenten
- Buchungen verweisen nur auf existierende Sachkonten im neuen Kontenplan
- Organisationsstrukturen (Kostenstellen, Profit-Center, Werke) sind vollständig angelegt
- Berechtigungsrelevante Zuordnungen (Benutzer zu Rollen, Rollen zu Organisationseinheiten) sind konsistent
Testmigration: Vertrauen durch Wiederholung
Eine Migration, die nicht getestet wurde, ist ein Glücksspiel. Testmigrationen sind der einzige Weg, um sicherzustellen, dass die Übernahme am Tag X funktioniert. Mindestens drei vollständige Testläufe sollten durchgeführt werden – idealerweise fünf.
Punkt 10: Testmigration vollständig durchführen
Eine Testmigration ist keine partielle Übung. Sie muss den produktiven Ablauf so genau wie möglich abbilden: gleiche Datenmengen, gleiche Transformationsregeln, gleicher Zeitdruck. Nur so werden die Probleme sichtbar, die am Go-Live-Tag auftreten werden.
- Mindestens drei vollständige Testmigrationen mit Produktionsdaten sind durchgeführt
- Jeder Testlauf umfasst alle Datenobjekte: Stammdaten, Bewegungsdaten, Finanzdaten
- Migrationszeit ist gemessen und dokumentiert – passt sie in das Cutover-Fenster?
- Fehlerprotokolle jedes Testlaufs sind analysiert und die Fehlerquote sinkt mit jedem Lauf
- Migrationsscripte und ETL-Prozesse sind versioniert und reproduzierbar
- Der letzte Testlauf wurde unter realistischen Bedingungen durchgeführt (Wochenende, gleicher Zeitrahmen)
Punkt 11: Migrationsergebnisse systematisch validieren
Nach jeder Testmigration muss validiert werden – nicht stichprobenartig, sondern systematisch. Automatisierte Prüfscripte sind manuellen Prüfungen immer vorzuziehen, weil sie reproduzierbar und vollständig sind.
- Mengenabgleich: Anzahl der Datensätze in Quelle und Ziel stimmt überein (je Datenobjekt)
- Werteabgleich: Summen über Beträge, Mengen und Salden stimmen überein
- Stichprobenprüfung durch Fachbereiche: Mindestens 5 % der Datensätze manuell geprüft
- Prozesstests im Zielsystem: Auftrag anlegen, Lieferschein erstellen, Rechnung buchen – mit migrierten Daten
- Automatisierte Validierungsscripte sind erstellt und dokumentiert
- Abweichungen sind dokumentiert, bewertet und Maßnahmen sind definiert
Punkt 12: Rollback-Plan definiert und getestet
Kein Go-Live ohne Rollback-Plan. Wenn die Migration scheitert – und das ist ein realistisches Szenario – muss das Unternehmen innerhalb eines definierten Zeitfensters auf das Altsystem zurückfallen können. Dieser Plan muss nicht nur existieren, sondern getestet sein.
- Rollback-Szenario ist dokumentiert: Wer entscheidet wann, und was passiert dann?
- Altsystem bleibt parallel betriebsbereit für einen definierten Zeitraum nach Go-Live
- Datensicherung des Altsystems unmittelbar vor der produktiven Migration ist geplant
- Rücksynchronisation: Falls im neuen System bereits gebucht wurde, wie werden diese Daten zurückgeführt?
- Kommunikationsplan für den Rollback-Fall ist erstellt (intern und extern)
- Rollback wurde mindestens einmal im Rahmen einer Testmigration durchgespielt
Go-Live Readiness: Die letzten Prüfungen vor dem Start
Die Go-Live Readiness umfasst alles, was über die reine Datenmigration hinausgeht, aber direkt davon abhängt: der Cutover-Zeitplan, die Verantwortlichkeiten und die Abnahmekriterien. Ohne diese drei Elemente ist ein Go-Live ein kontrolliertes Risiko – bestenfalls.
Punkt 13: Cutover-Zeitplan minutengenau geplant
Der Cutover-Plan ist der Drehbuchtext für den Go-Live. Er beschreibt minutengenau, wann welcher Schritt ausgeführt wird, wer verantwortlich ist und wie lange jeder Schritt dauern darf. Ein guter Cutover-Plan hat Pufferzeiten und Eskalationspunkte.
- Cutover-Plan liegt als detaillierter Ablaufplan mit Uhrzeiten vor
- Jeder Schritt hat einen Verantwortlichen, eine geschätzte Dauer und ein Erfolgskriterium
- Pufferzeiten sind eingeplant – mindestens 20 % der Gesamtdauer
- Eskalationspunkte sind definiert: Wann wird die Go/No-Go-Entscheidung getroffen?
- Kommunikation ist geplant: Wer informiert wann Mitarbeiter, Kunden und Lieferanten?
- Technische Voraussetzungen (Systemverfügbarkeit, Netzwerk, Zugriffsrechte) sind bestätigt
Punkt 14: Verantwortlichkeiten klar zugeordnet
Am Go-Live-Tag gibt es keinen Raum für Rückfragen wie „Wer kümmert sich darum?“. Jede Aufgabe muss einem konkreten Menschen zugeordnet sein – nicht einer Abteilung, nicht einem Team, sondern einer Person mit Namen und Erreichbarkeit.
- Migrationsverantwortlicher (gesamt) ist benannt und verfügbar am Go-Live-Wochenende
- Je Datenbereich ist ein Fachverantwortlicher benannt (Stammdaten, Finanzen, Logistik)
- Technischer Ansprechpartner für das Zielsystem ist verfügbar und erreichbar
- Ansprechpartner beim ERP-Anbieter oder Implementierungspartner ist mit Rufbereitschaft gesichert
- Vertretungsregelungen sind definiert für den Fall von Ausfällen
- Kontaktliste mit Telefonnummern aller Beteiligten ist gedruckt und verteilt – nicht nur digital
Punkt 15: Abnahmekriterien definiert und vereinbart
Ohne klare Abnahmekriterien gibt es keine objektive Grundlage für die Go/No-Go-Entscheidung. Abnahmekriterien müssen messbar sein – nicht „Daten sehen gut aus“, sondern „Mengenabweichung kleiner 0,1 %, Summenabweichung gleich Null“.
- Quantitative Abnahmekriterien sind definiert: Mengenabgleich, Summenabgleich, Fehlerquote
- Qualitative Abnahmekriterien sind definiert: Stichprobenprüfung durch Fachbereiche bestanden
- Prozesstests sind bestanden: Kernprozesse (Auftrag-to-Cash, Procure-to-Pay) laufen mit migrierten Daten
- Abnahmeprotokoll ist vorbereitet und die Unterschriftenberechtigten sind informiert
- Go/No-Go-Entscheidungspunkt ist terminiert – mit ausreichend Zeit vor dem Point-of-no-Return
- Nachmigrationsplan ist erstellt: Welche Korrekturen werden in den ersten Tagen nach Go-Live durchgeführt?
Migrationszeitplan: Wann was passieren muss
Die Migration beginnt nicht zwei Wochen vor dem Go-Live. Sie beginnt drei Monate vorher – mindestens. Der folgende Zeitplan zeigt, wann welche Aktivitäten abgeschlossen sein müssen, damit der Go-Live-Termin realistisch bleibt.
Von der Vorbereitung zum Go-Live
T–12 Wochen
Migrationskonzept und Mapping
Migrationsstrategie festlegen, Datenobjekte inventarisieren, Feld-Mapping zwischen Quell- und Zielsystem erstellen, Transformationsregeln definieren. Verantwortlichkeiten im Migrationsteam zuordnen.
T–8 Wochen
Datenbereinigung und erste Testmigration
Dublettenanalyse durchführen, Pflichtfelder auffüllen, Datenqualität messen. Erste vollständige Testmigration mit anschließender Validierung. Fehlerprotokoll erstellen und Korrekturen einleiten.
T–4 Wochen
Iterative Testmigrationen
Zweite und dritte Testmigration durchführen. Fehlerquote messen und mit vorherigen Läufen vergleichen. Migrationszeit optimieren. Fachbereiche für Stichprobenprüfungen einbinden.
T–2 Wochen
Finale Validierung und Cutover-Planung
Letzte Testmigration unter Produktivbedingungen. Cutover-Plan finalisieren. Rollback-Szenario testen. Abnahmekriterien final abstimmen. Go/No-Go-Meeting vorbereiten.
Go-Live
Produktive Migration und Abnahme
Altsystem einfrieren, produktive Migration durchführen, automatisierte und manuelle Validierung, Abnahmeprotokoll unterzeichnen, System freigeben. Monitoring der ersten Buchungen und Transaktionen.
Strukturierte vs. Ad-hoc Datenmigration
Der Unterschied zwischen einer strukturierten und einer improvisierten Migration zeigt sich nicht in der Theorie, sondern am Go-Live-Tag. Die folgende Gegenüberstellung macht deutlich, warum eine systematische Vorgehensweise keine Option, sondern eine Notwendigkeit ist.
Zwei Wege zur Datenmigration
Strukturierte Migration
Ad-hoc Migration
Planung
Migrationskonzept ab Projektstart, dediziertes Team, klare Meilensteine
Migration wird als Teilaufgabe des Customizings behandelt, keine eigene Planung
Datenqualität
Systematische Analyse und Bereinigung vor der ersten Testmigration
Datenprobleme werden erst während der Migration entdeckt und ad hoc behoben
Testmigrationen
3–5 vollständige Durchläufe mit dokumentierten Ergebnissen und sinkender Fehlerquote
Ein oder zwei partielle Tests, Ergebnisse werden nicht systematisch ausgewertet
Validierung
Automatisierte Prüfscripte, Mengen- und Werteabgleich, Prozesstests mit Fachbereichen
Stichprobenartige manuelle Prüfung durch Einzelpersonen
Rollback
Dokumentierter und getesteter Rollback-Plan mit klaren Entscheidungskriterien
Kein Rollback-Plan oder nur theoretisch beschrieben, nie getestet
Go-Live-Ergebnis
Kontrollierter Start, geringe Nacharbeiten, schnelle Stabilisierung
Chaotischer Start, wochenlange Nacharbeiten, Vertrauensverlust bei Anwendern
Fazit: Migration ist kein IT-Thema – es ist ein Projektrisiko
Die 15 Prüfpunkte in dieser Checkliste sind kein Übermaß an Bürokratie. Sie sind das Ergebnis von Projekten, in denen genau diese Punkte nicht geprüft wurden – mit entsprechenden Konsequenzen. Wer die Datenmigration als technische Aufgabe behandelt, die irgendwann am Ende des Projekts erledigt wird, riskiert den gesamten Projekterfolg.
Datenmigration ist kein Sprint am Ende. Sie ist ein durchgängiger Prozess, der mit der Konzeptphase beginnt und erst Wochen nach dem Go-Live wirklich abgeschlossen ist. Die Checkliste hilft, diesen Prozess strukturiert zu steuern – und die richtigen Fragen zum richtigen Zeitpunkt zu stellen.
DATAudit360: Datenqualität sichtbar machen
Wie steht es um die Datenqualität in Ihrem Unternehmen? Mit dem DATAudit360 analysiert Innovera Ihren Datenbestand systematisch – von Stammdaten über Dubletten bis zu fehlenden Pflichtfeldern. Das Ergebnis ist ein klarer Bericht mit konkreten Handlungsempfehlungen, der Ihnen zeigt, wo Sie vor der Migration ansetzen müssen. Sprechen Sie uns an – bevor der Migrationsstichtag das Problem sichtbar macht.
Wenn Sie dieses Thema in Ihrem Projekt vertiefen möchten, sprechen Sie mit uns.