Der Datenlauf ist abgeschlossen, doch im neuen ERP fehlen Datensätze, die im Altsystem oder im ursprünglichen Export noch vorhanden waren. Vielleicht zeigt das Ziel weniger Kunden, Materialien oder offene Vorgänge. Vielleicht fällt die Lücke erst auf, weil ein Keyuser einen bekannten Datensatz nicht findet. Dann sollte das Team die fehlenden Einträge nicht sofort von Hand nacherfassen.
Wenn Daten nach der ERP-Migration fehlen, muss zuerst der früheste Verarbeitungspunkt gefunden werden, an dem die betroffenen Schlüssel verschwinden. Dazu wird derselbe vereinbarte Datenbestand von der Quelle über Auswahl, Export, Transformation und Import bis ins Ziel verfolgt. Erst diese Spur zeigt, ob Datensätze ausgefiltert, durch eine Verknüpfung verloren, zusammengeführt, abgewiesen oder im Ziel lediglich nicht sichtbar sind.
Die entscheidende Frage lautet deshalb nicht nur: „Wie viele Datensätze fehlen?“ Sie lautet: „Welche Datensätze fehlen seit welchem Schritt – und aus welchem dokumentierten Grund?“
Daten fehlen nach der ERP-Migration: Die kurze Antwort
Eine belastbare Fehlersuche beginnt mit einer Datensatzspur. Damit ist eine Übersicht gemeint, die denselben fachlichen Schlüssel an jedem Verarbeitungspunkt verfolgt. Für einen Kunden könnte das beispielsweise die alte Kundennummer sein, für ein Material die bisherige Artikelnummer und für einen offenen Vorgang eine Kombination aus Beleg- und Positionsnummer.
Für jeden Kontrollpunkt werden mindestens drei Dinge festgehalten:
- Welche Datensätze nach der vereinbarten Auswahl enthalten sein sollen,
- welche eindeutigen Schlüssel dort tatsächlich vorkommen und
- warum ein Schlüssel bewusst entfällt, verändert oder zusammengeführt wird.
So wird eine Mengendifferenz zu einer erklärbaren Liste. Der Fehler lässt sich anschließend an seiner Ursache beheben, statt die sichtbare Lücke im Zielsystem zu überdecken.
Zuerst klären: Fehlt der Datensatz wirklich im Ziel?
„Nicht gefunden“ und „nicht importiert“ sind nicht immer dasselbe. Ein Datensatz kann im Ziel vorhanden sein, aber unter einem neuen Schlüssel, in einer anderen Organisationseinheit oder mit einem Status, den die aktuelle Ansicht ausblendet. Auch Rollen und Berechtigungen können beeinflussen, was ein Keyuser sieht.
Bevor die technische Verarbeitung untersucht wird, sollten deshalb Zielsystemteam und Fachbereich gemeinsam prüfen:
- Wurde mit dem alten oder dem neuen Schlüssel gesucht?
- Ist die richtige Gesellschaft, Niederlassung oder Organisation ausgewählt?
- Blendet die verwendete Liste inaktive oder gesperrte Datensätze aus?
- Ist nur das Hauptobjekt vorhanden, während eine Rolle oder Zuordnung fehlt?
- Zeigt eine technische Zielauswertung denselben Befund wie die Oberfläche?
Diese Gegenprüfung verhindert eine riskante Doppelanlage. Wird ein vorhandener, aber in der Oberfläche verborgener Datensatz erneut erfasst, entsteht aus dem vermeintlichen Verlust möglicherweise eine Dublette.
Die Datensatzspur folgt sechs Kontrollpunkten
Ist die Lücke bestätigt, wird der betroffene Schlüssel rückwärts durch den tatsächlichen Lauf verfolgt. Die Kontrollpunkte müssen zum verwendeten Verfahren passen; in einer dateibasierten Migration sind meist diese sechs Stationen sinnvoll:
- Quellbestand: Der Datensatz existiert im festgelegten Quellsystem und Datenstand.
- Auswahlmenge: Er erfüllt die bestätigten Filter für Gesellschaft, Status, Zeitraum und Migrationsumfang.
- Export: Der Schlüssel ist in der technisch erzeugten Rohdatei enthalten.
- Transformation: Er erscheint nach Mapping, Bereinigung, Zusammenführung und Formatierung in der ladebereiten Datei.
- Importverarbeitung: Das Zielsystem hat ihn angenommen, abgewiesen oder nur teilweise verarbeitet.
- Zielbestand: Der Datensatz und seine benötigten Beziehungen sind in der richtigen Zielorganisation vorhanden und fachlich auffindbar.
Der erste Kontrollpunkt, an dem der Schlüssel fehlt, begrenzt die Suche. Ist er bereits nicht in der Auswahlmenge enthalten, helfen keine Änderungen am Import. Kommt er bis zur Importdatei, fehlt aber im Ziel, müssen Importstatus, Abhängigkeiten und Zielverarbeitung untersucht werden.
Ursache 1: Eine Auswahlregel schließt mehr Daten aus als beabsichtigt
Filter sind notwendig, weil nicht jeder historische oder inaktive Datensatz ins neue ERP gehört. Problematisch werden sie, wenn ihre fachliche Wirkung nicht als konkrete Menge geprüft wurde. Ein Statuswert kann im alten System beispielsweise anders verwendet worden sein als angenommen. Ein Stichtagsfilter kann offene Vorgänge ausschließen, deren Belegdatum alt ist, deren Restmenge aber weiterhin relevant bleibt.
Die Prüfung darf daher nicht bei der SQL-Bedingung oder dem Exportdialog enden. Zu jeder Auswahlregel gehört eine Liste der ausgeschlossenen Schlüssel samt Grund. Der Fachbereich kann dann beurteilen, ob die Regel die gewünschte Teilmenge trifft.
Wurde der Datensatz bewusst ausgeschlossen, fehlt er nicht versehentlich. Dann braucht das Projekt einen nachvollziehbaren Scope-Nachweis. Wurde er dagegen unbeabsichtigt ausgeschlossen, muss die Auswahlregel korrigiert und der gesamte von ihr betroffene Bestand erneut geprüft werden.
Ursache 2: Eine Tabellenverknüpfung lässt gültige Ausgangssätze verschwinden
Ein Zielobjekt entsteht häufig aus mehreren Quelltabellen. Dabei kann eine technische Verknüpfung Datensätze entfernen, obwohl der Hauptsatz vorhanden ist. Das geschieht beispielsweise, wenn eine Abfrage nur Zeilen behält, für die auch in einer abhängigen Tabelle ein passender Eintrag gefunden wird.
Eine solche innere Verknüpfung – in SQL als INNER JOIN bezeichnet – ist richtig, wenn die abhängige Information zwingend vorhanden sein muss. Ist sie jedoch optional oder im Altsystem nicht durchgehend gepflegt, verschwindet der Hauptdatensatz unbemerkt aus dem Ergebnis.
Deshalb sollte jede Verbindung nicht nur fachlich beschrieben, sondern auch mengenmäßig geprüft werden:
- Wie viele Hauptschlüssel gibt es vor der Verknüpfung?
- Wie viele bleiben danach erhalten?
- Welche Schlüssel gehen verloren?
- Fehlt tatsächlich eine erforderliche Beziehung, oder ist die Verknüpfungsart zu streng?
Der Beitrag Mehrere SQL-Tabellen in eine ERP-Importdatei umwandeln vertieft, wie solche Beziehungen technisch erhalten bleiben.
Ursache 3: Zusammenführung und neue Schlüssel verändern die sichtbare Menge
Nicht jede kleinere Zielmenge ist ein Fehler. Werden bestätigte Dubletten zusammengeführt, entstehen aus mehreren Quellsätzen bewusst weniger Zielobjekte. Ebenso kann ein alter Schlüssel durch eine neue Nummer ersetzt werden. Dann ist der ursprüngliche Datensatz im Ziel nicht unter seiner bisherigen Identität auffindbar.
Damit dieser Unterschied nicht wie Datenverlust wirkt, braucht jede beabsichtigte Mengenänderung eine Rechenbrücke:
relevante Quellsätze – bestätigte Ausschlüsse – zusammengeführte Dubletten + bewusst neu angelegte Sätze = erwartete Zielmenge.
Zusätzlich ist eine Schlüsselliste erforderlich, die alte und neue Identitäten verbindet. Eine übereinstimmende Gesamtzahl ohne diese Zuordnung kann täuschen: Es könnten gleichzeitig benötigte Datensätze fehlen und unerwünschte Datensätze enthalten sein.
Ursache 4: Der Import war nur teilweise erfolgreich
Viele Importverfahren verarbeiten gültige Zeilen weiter, obwohl andere Zeilen abgewiesen werden. Der Job kann dadurch insgesamt beendet oder sogar als erfolgreich dargestellt werden, während einzelne Datensätze im Fehlerbereich, in einer Zwischentabelle oder in einem unvollständigen Status verbleiben.
Das Importprotokoll muss deshalb auf der Ebene der betroffenen Schlüssel ausgewertet werden. Benötigt werden nicht nur die Gesamtmeldungen, sondern mindestens:
- erfolgreich angelegte oder aktualisierte Schlüssel,
- abgewiesene und teilweise verarbeitete Schlüssel,
- der konkrete Fehlergrund,
- die verwendete Datei und Jobkennung sowie
- die Zielvoraussetzung, die für eine Wiederholung fehlt.
Ein erneuter Komplettimport ohne diese Trennung kann bereits geladene Datensätze doppelt verarbeiten. Sicherer ist eine kontrollierte Fehlerteilmenge oder ein technisch vorgesehener Wiederanlauf, dessen Wirkung anschließend erneut gegen die Datensatzspur geprüft wird.
Ursache 5: Abhängige Daten wurden in der falschen Reihenfolge geladen
Ein Datensatz kann fachlich und technisch korrekt vorbereitet sein, aber von einem noch nicht vorhandenen Zielobjekt abhängen. Eine Position benötigt ihren Kopf, ein Ansprechpartner seinen Geschäftspartner und ein Organisationsdatensatz die zuvor eingerichtete Organisationseinheit. Fehlt diese Voraussetzung, kann das Zielsystem den abhängigen Satz abweisen oder unvollständig verarbeiten.
Die Lösung besteht nicht darin, die Abhängigkeit zu umgehen. Zuerst wird die vorgesehene Ladereihenfolge bestätigt. Anschließend werden Haupt- und Unterobjekte über ihre Schlüssel verbunden und in einem kleinen Nachtest gemeinsam geprüft. Für den produktiven Lauf muss diese Reihenfolge im Cutover-Plan der Datenmigration mit Laufzeit und Verantwortlichkeit hinterlegt sein.
Warum reine Mengenzählungen die Ursache nicht finden
Gesamtzahlen zeigen, dass eine Differenz besteht. Sie zeigen aber nicht, aus welchen Schlüsseln sie besteht. Für die Diagnose braucht es deshalb einen Schlüsselvergleich zwischen zwei benachbarten Kontrollpunkten.
Technisch lässt sich ermitteln:
- welche Schlüssel links vorhanden und rechts nicht vorhanden sind,
- welche unerwartet neu auftauchen,
- welche mehrfach vorkommen und
- welche aufgrund einer dokumentierten Regel ihre Identität wechseln.
Dieser Vergleich wird immer nur zwischen zwei Stationen durchgeführt. Dadurch bleibt er entscheidbar. Eine große Liste „Quelle gegen Ziel“ vermischt dagegen Auswahl, Transformation und Import zu einem einzigen Befund und sagt nicht, wo die Korrektur hingehört.
Vier schnelle Reparaturen können die Lücke verschlimmern
Die fehlenden Sätze manuell neu anzulegen kann bei einzelnen bestätigten Ausnahmen sinnvoll sein. Ohne Ursachenprüfung besteht jedoch das Risiko, versteckte vorhandene Sätze zu duplizieren und die wiederholbare Migration zu verlassen.
Die komplette Datei erneut zu importieren ist sinnvoll, wenn das Zielverfahren einen sicheren Wiederanlauf unterstützt und der Zielstand bekannt ist. Andernfalls können bereits erfolgreiche Sätze doppelt angelegt oder unbeabsichtigt überschrieben werden.
Nur die Gesamtzahlen passend zu machen liefert einen ersten Kontrollwert. Es beweist aber weder die Identität noch die fachliche Richtigkeit der angekommenen Datensätze.
Die Importdatei direkt zu reparieren kann einen Test kurzfristig retten. Bleibt die Ursache jedoch in Filter, Mapping oder Transformationsskript bestehen, erzeugt der nächste Export dieselbe Lücke erneut.
So wird aus der Abweichung eine behobene Ursache
Wir führen einen fehlenden Datensatz nicht nur bis zum Fehler, sondern auch durch die Korrektur zurück in den nächsten Lauf. Dafür genügt ein schlanker Ablauf:
- Verwendeten Quellstand, Dateien, Regelversion, Importjob und Zielumgebung sichern.
- Betroffene Schlüssel und vereinbarte Grundgesamtheit festhalten.
- Den frühesten abweichenden Kontrollpunkt bestimmen.
- Die Ursache in Auswahl, Verknüpfung, Mapping, Transformation, Import oder Zielanzeige beheben.
- Eine gezielte Fehlerteilmenge erneut verarbeiten.
- Betroffene und angrenzende Regeln kontrollieren.
- Erst nach bestandenem Schlüssel- und Fachabgleich den Befund schließen.
Die umfassendere Datenvalidierung bei der ERP-Migration ordnet diesen Vollständigkeitsnachweis gemeinsam mit technischer Gültigkeit, fachlicher Richtigkeit und Prozessnutzbarkeit ein. Wenn mehrere Fehlerarten gleichzeitig auftreten und der gesamte Testlauf nicht mehr belastbar ist, hilft die Ursachenstruktur aus ERP-Datenmigration fehlgeschlagen.
Wer die Datensatzspur verantwortet
Die interne Projektleitung bestätigt den betrachteten Umfang und bewertet die Auswirkung auf Test oder Go-live. Der Fachbereich entscheidet über fachliche Ausschlüsse, Zusammenführungen und erwartete Zielbeziehungen. Der ERP-Partner erklärt Importstatus, Zielvoraussetzungen und technisch vorgesehene Wiederanläufe.
Wir können die Verarbeitungskette technisch nachvollziehbar machen, Schlüsselvergleiche und Mengennachweise automatisieren, Verluststellen in Export oder Transformation lokalisieren und Korrekturen in einen wiederholbaren Datenlauf überführen. Fachliche Freigaben und die Entscheidung über den produktiven Einsatz verbleiben beim Unternehmen.
Fehlende Datensätze werden am ersten Bruch behoben
Wenn Daten nach einer ERP-Migration fehlen, ist der sichtbare Zielbestand nur der letzte Kontrollpunkt. Die Ursache kann deutlich früher liegen: in der Auswahl, einer Tabellenverknüpfung, einer Zusammenführung, einem Teilimport oder der Zielanzeige.
Eine Datensatzspur macht diesen Weg für jeden betroffenen Schlüssel sichtbar. Dadurch muss das Team nicht raten oder Zielbestände manuell flicken. Es korrigiert genau die Regel oder Verarbeitung, an der der Datensatz verloren ging, und kann im nächsten Lauf belegen, dass die Lücke dauerhaft geschlossen ist.