Am Montag wird der Kundenstamm erfolgreich testweise migriert. Bis zum produktiven Start am Freitag legt der Vertrieb neue Kunden an, ändert Lieferadressen und sperrt einen zahlungsunfähigen Debitor. Der Test hat die Migrationsregeln bestätigt – aber sein Datenstand ist beim Go-live bereits veraltet.
Eine Delta-Migration im ERP-Projekt übernimmt genau die neuen, geänderten und nicht mehr gültigen Informationen, die seit einem festgehaltenen Ausgangsstand entstanden sind. Sie ist jedoch nicht automatisch die beste Lösung. Wenn ein vollständiger, aktueller Datenlauf sicher in das verfügbare Zeitfenster passt, ist er häufig einfacher. Ein Delta wird vor allem dann sinnvoll, wenn Daten bereits vorgeladen wurden oder der vollständige Lauf zu lange dauern würde.
Die entscheidende Frage lautet deshalb nicht nur, seit wann sich ein Datensatz geändert hat. Das Projekt muss für jedes Datenobjekt festlegen, welche Veränderungen erkannt werden, welche Aktion daraus im Ziel entsteht und wie der finale Bestand anschließend vollständig nachgewiesen wird.
Delta Migration ERP: Die kurze Antwort
Zwischen Testlauf und Go-live werden vier Arten von Veränderungen beherrscht:
- neue Datensätze,
- geänderte Werte in vorhandenen Datensätzen,
- Löschungen, Sperren oder andere Statuswechsel sowie
- neue oder veränderte Beziehungen, etwa ein zusätzlicher Ansprechpartner oder eine andere Organisationszuordnung.
Für jedes Datenobjekt wird zunächst entschieden, ob zum Go-live ein frischer Volllauf, eine Vorladung mit anschließendem Delta oder ein kurzer Datenstopp mit vollständigem Schlusslauf sicherer ist. Nur wenn ein Delta gewählt wird, braucht es einen eindeutigen Ausgangsstand, stabile Schlüssel, eine vollständige Änderungslogik und einen getesteten Abgleich von Quelle und Ziel.
Eine Testmigration ist nicht automatisch die technische Basis des Deltas
Testmigrationen laufen üblicherweise in einem Testsystem. Dort werden Auswahl, Mapping, Transformation, Import und fachliche Prüfung erprobt. Der Datenstand dient als Beweis, dass der Ablauf funktioniert. Er wird deshalb nicht automatisch zum vorbeladenen Bestand des späteren Produktivsystems.
Für den Go-live gibt es zwei unterschiedliche Situationen:
- Frischer Produktivlauf: Aus dem aktuellen Altsystem wird nach dem Datenstopp der gesamte bestätigte Umfang neu erzeugt und in ein vorbereitetes Produktivsystem geladen.
- Vorladung mit Delta: Ein vollständiger Bestand wird vor dem Go-live bereits in das spätere Ziel geladen. Danach werden nur die seit diesem genau dokumentierten Stand entstandenen Veränderungen ergänzt.
Der Ausdruck „Delta seit der Testmigration“ ist daher nur korrekt, wenn der getestete Ausgangsstand technisch wirklich die Basis der produktiven Vorladung bildet. Andernfalls liefert die Testmigration zwar Regeln und Laufzeiten, aber keinen Ausgangsbestand für das Produktivdelta.
Zuerst prüfen: Ist ein vollständiger Schlusslauf einfacher?
Ein Delta spart Laufzeit, erhöht aber die fachliche und technische Komplexität. Das Projekt muss Änderungen vollständig erkennen, mehrfaches Laden sicher behandeln und den vorgeladenen Bestand mit dem Delta zu einem richtigen Gesamtstand verbinden.
Ein frischer Volllauf ist häufig die bessere Wahl, wenn:
- Export, Transformation, Import und Prüfung in das Cutover-Fenster passen,
- der Zielbestand vor dem Lauf kontrolliert zurückgesetzt werden kann,
- Abhängigkeiten in einer erprobten Reihenfolge vollständig neu geladen werden und
- der vollständige Lauf mehrfach mit realistischem Volumen getestet wurde.
Eine Vorladung mit Delta wird interessanter, wenn große Datenmengen oder langsame Zielimporte das verfügbare Zeitfenster überschreiten. Sie kann auch sinnvoll sein, wenn umfangreiche Stammdaten früh fachlich geprüft werden sollen und sich bis zum Go-live nur eine begrenzte Teilmenge verändert. Diese Entscheidung wird nicht für das gesamte Projekt pauschal getroffen. Ein großer Materialstamm kann eine andere Strategie benötigen als offene Aufträge, Bestände oder Salden.
Vier Veränderungsarten müssen getrennt behandelt werden
| Veränderung in der Quelle | Notwendige Zielaktion | Typisches Risiko |
|---|---|---|
| Neuer Datensatz | Neues Zielobjekt mit allen Pflichtbeziehungen anlegen | Der Hauptsatz wird erkannt, eine abhängige Adresse oder Organisation aber nicht. |
| Geänderter Wert | Vorhandenes Zielobjekt anhand eines stabilen Schlüssels aktualisieren | Der Datensatz wird ein zweites Mal angelegt oder nur teilweise überschrieben. |
| Löschung, Sperre oder Statuswechsel | Bestätigte Zielreaktion wie sperren, beenden, aus dem Umfang nehmen oder löschen | Ein nicht mehr vorhandener Quellsatz erscheint in einem normalen Deltaexport gar nicht. |
| Neue oder geänderte Beziehung | Verknüpfung nach dem betroffenen Hauptobjekt aktualisieren | Beide Einzelsätze sind vorhanden, hängen im Ziel aber falsch zusammen. |
Diese Trennung ist wichtig, weil ein einfacher Filter auf „Änderungsdatum größer als Stichtag“ meist nur einen Teil der Fälle sicher findet. Eine gelöschte Zeile trägt im aktuellen Export keinen neuen Zeitstempel mehr. Eine Änderung in einer zugehörigen Tabelle kann die fachliche Aussage eines Hauptsatzes verändern, ohne dessen Änderungsdatum anzufassen.
Der Ausgangsstand muss wie ein prüfbarer Vertrag festgehalten werden
Die Grundlage jedes Deltas ist ein eindeutiger Ausgangsstand. Man kann ihn als Baseline bezeichnen – gemeint ist schlicht der dokumentierte Bestand, ab dem spätere Veränderungen gezählt werden. Dazu gehören:
- Quelle, Mandant und verwendeter Exportweg,
- Stichtag mit Uhrzeit und Zeitzone,
- Selektionsfilter und Migrationsumfang,
- Anzahl und Schlüsselmenge je Datenobjekt,
- verwendete Mapping- und Transformationsversion sowie
- der dazugehörige Ziel- oder Vorladestand.
Ein Zeitstempel allein genügt nicht. Wenn zwischen zwei Läufen auch Selektionsfilter, Mappingregeln oder Zielkonfigurationen verändert wurden, enthält die Differenz nicht nur neue Geschäftsdaten. Sie enthält zugleich eine geänderte Migrationslogik. Dann muss geprüft werden, ob bereits vorgeladene Datensätze erneut verarbeitet werden müssen.
So lassen sich Veränderungen vollständig ermitteln
Welcher technische Weg geeignet ist, hängt von der Quelle ab. Häufig kommen vier Verfahren infrage:
- Zuverlässige Änderungszeitpunkte: Datensätze werden anhand eines systematisch gepflegten Erstellungs- und Änderungszeitpunkts ausgewählt.
- Änderungs- oder Protokolltabellen: Das Altsystem zeichnet anlegen, ändern, sperren und löschen als Ereignisse auf.
- Vergleich zweier vollständiger Auszüge: Schlüssel und relevante Werte des Ausgangsstands werden mit einem neuen Export verglichen.
- Fachliche Bewegungs- und Statuslogik: Für offene Aufträge, Bestände oder Salden wird der aktuelle fachliche Stichtagsbestand neu bestimmt, statt nur technische Feldänderungen zu sammeln.
Vor der Entscheidung wird das gewählte Signal getestet. Dazu gehören mindestens ein neu angelegter Satz, eine Änderung an einer Hauptinformation, eine Änderung in einer abhängigen Tabelle, eine Sperre, eine Löschung und eine rückwirkend erfasste Änderung. Nur wenn alle relevanten Fälle erscheinen, darf das Signal den finalen Lauf steuern.
Fehlt ein belastbares Änderungsprotokoll, ist der Vergleich zweier vollständiger Auszüge oft sicherer als ein vermeintlich präziser, aber lückenhafter Zeitstempelfilter. Er benötigt zwar mehr Verarbeitung, macht dafür auch verschwundene Schlüssel sichtbar.
Die Ladelogik muss Wiederholungen ohne Dubletten verkraften
Ein Deltalauf kann abbrechen. Einzelne Datensätze können technisch zurückgewiesen werden, während andere bereits im Ziel angekommen sind. Deshalb muss vorab feststehen, was bei einer Wiederholung passiert.
Für jeden Satz braucht die Zielverarbeitung eine eindeutige Antwort:
- Woran erkennt sie, ob das Zielobjekt bereits existiert?
- Wird ein vorhandener Wert aktualisiert, ergänzt oder bewusst nicht überschrieben?
- Wie werden abhängige Sätze in der richtigen Reihenfolge verarbeitet?
- Was geschieht mit einer bereits ausgeführten Sperre oder Beendigung?
- Wie kann nur die fehlerhafte Teilmenge erneut geladen werden?
Der sichere Zustand ist erreicht, wenn derselbe bestätigte Deltalauf erneut verarbeitet werden kann, ohne neue Dubletten oder eine andere fachliche Wirkung zu erzeugen. Ob das jeweilige ERP-Importwerkzeug diese Aktualisierungslogik unterstützt, muss der Zielsystempartner für jedes Migrationsobjekt bestätigen.
Ein Datenstopp schließt die letzte offene Lücke
Solange Nutzer, Schnittstellen oder Hintergrundläufe das Altsystem verändern, wandert der Zielpunkt weiter. Deshalb benötigt auch eine Delta-Strategie einen klaren Datenstopp – häufig Freeze genannt. Dabei wird festgelegt, ab wann welche Änderungen in der Quelle nicht mehr zulässig sind.
Der Stopp muss mehr beantworten als eine Uhrzeit:
- Dürfen Nutzer nur nicht mehr buchen oder auch keine Stammdaten ändern?
- Werden automatische Schnittstellen und zeitgesteuerte Jobs angehalten?
- Wie werden unvermeidbare Notfälle dokumentiert und nachgeführt?
- Wer bestätigt, dass Quelle und gegebenenfalls vorbeladenes Ziel stillstehen?
- Ab welchem Zeitpunkt arbeitet das Unternehmen ausschließlich im neuen ERP?
Ein sehr früher Stopp kann den Geschäftsbetrieb unnötig behindern. Ein zu später oder unvollständiger Stopp erzeugt dagegen Daten, die weder im letzten Delta noch sicher im neuen System landen. Die passende Dauer ergibt sich aus gemessener Export-, Transformations-, Import- und Prüfzeit.
Der finale Abgleich beweist mehr als einen erfolgreichen Import
Nach dem Delta muss sich der erwartete Gesamtstand rechnerisch und fachlich erklären lassen. Für einfache Bestände beginnt das mit einer Mengenbrücke:
bestätigter Ausgangsbestand + neue Sätze − entfernte Sätze ± bewusst zusammengeführte oder ausgeschlossene Fälle = erwarteter Zielbestand.
Zusätzlich werden alle geänderten Schlüssel gegen ihre erwarteten Zielwerte geprüft. Bei abhängigen Objekten kommen Beziehungszahlen hinzu, etwa Ansprechpartner je Kunde oder Positionen je Auftrag. Summen, Bestände und Salden benötigen eigene fachliche Abgleiche.
Wichtig ist auch eine unveränderte Vergleichsgruppe. Wenn ein Delta ausschließlich geänderte Kunden verarbeiten sollte, müssen einige bewusst unveränderte Kunden nach dem Lauf denselben Zielstand behalten. Dadurch wird sichtbar, ob die Aktualisierung versehentlich bereits bestätigte Daten überschrieben hat.
Wie Mengen, Werte, Beziehungen und Prozesse gemeinsam geprüft werden, vertieft der Beitrag zur Datenvalidierung bei der ERP-Migration.
Vier Abkürzungen, die das Delta unsicher machen
Nur das letzte Änderungsdatum filtern: Das funktioniert, wenn dieses Feld für alle relevanten Haupt- und Unterinformationen zuverlässig gepflegt wird. Ohne Test auf Löschungen, Rückdatierungen und abhängige Tabellen bleibt die Auswahl unvollständig.
Die fertige Testdatei kurz vor dem Go-live manuell ergänzen: Bei wenigen bestätigten Ausnahmefällen kann eine kontrollierte Nachpflege vertretbar sein. Als allgemeines Verfahren fehlen Wiederholbarkeit, Herkunft und ein vollständiger Nachweis.
Den vorgeladenen Bestand einfach noch einmal vollständig importieren: Das ist nur sicher, wenn Ziel und Importlogik einen erneuten Volllauf kontrolliert ersetzen oder aktualisieren. Andernfalls entstehen Dubletten oder alte und neue Versionen nebeneinander.
Das Altsystem sehr früh einfrieren: Dadurch sinkt die technische Delta-Menge, aber das Unternehmen muss länger außerhalb seines regulären Systems arbeiten. Das verlagert Änderungen in Notizlisten und schafft ein neues Nachpflegeproblem.
Testläufe müssen nicht nur die Daten, sondern auch die Delta-Logik prüfen
Ein technisch entwickeltes Delta ist erst belastbar, wenn es mindestens einmal unter realistischen Bedingungen wiederholt wurde. Der Test beginnt mit einem bekannten Ausgangsstand. Danach werden bewusst neue, geänderte, gesperrte, gelöschte und rückwirkend erfasste Fälle erzeugt. Der Lauf muss genau diese Fälle finden, richtig in das Ziel übertragen und beim erneuten Start stabil bleiben.
Auch die Laufzeit gehört zum Ergebnis. Ein Delta, das in der Entwicklung mit wenigen Sätzen funktioniert, kann am Go-live an Protokollmengen, Zielprüfungen oder seriellen Importen scheitern. Der Beitrag Wie viele Testläufe eine ERP-Datenmigration braucht ordnet ein, wann ein vollständiger Lauf und wann ein gezielter Nachtest sinnvoll ist.
Das Delta ist ein Baustein des Cutovers, nicht der gesamte Cutover
Dieser Beitrag beantwortet, wie Veränderungen zwischen einem festgehaltenen Ausgangsstand und dem Go-live erkannt, geladen und abgeglichen werden. Der gesamte Cutover enthält darüber hinaus Systembereitstellung, Verantwortlichkeiten, Laufreihenfolge, Kommunikation, Go-/No-go-Kriterien und einen Rückfallweg.
Diese übergreifende Ablaufplanung gehört in den ERP-Cutover-Plan für die Datenmigration. Dort wird die gewählte Voll- oder Delta-Strategie mit Startzeit, Dauer, Abhängigkeiten, Freigaben und Verantwortlichen zu einem ausführbaren Go-live-Ablauf verbunden.
Wer entscheidet und wer setzt um?
Die ERP-Projektleitung entscheidet gemeinsam mit den Fachbereichen, wie lange der Geschäftsbetrieb unterbrochen werden darf und welche fachlichen Änderungen bis zu welchem Zeitpunkt zulässig sind. Der Zielsystempartner bestätigt, wie vorhandene Objekte aktualisiert, abhängige Daten geladen und fehlerhafte Teilmengen wiederholt werden können.
Wir können Quelländerungen technisch analysieren, Voll- und Delta-Varianten anhand gemessener Laufzeiten vergleichen, eine wiederholbare Änderungslogik umsetzen und den finalen Abgleich vorbereiten. Ob eine Löschung im Altsystem im neuen ERP ebenfalls zur Löschung, zu einer Sperre oder zu einer bewussten Übernahme führt, bleibt eine fachliche Entscheidung des Unternehmens.
Der Go-live braucht einen aktuellen und erklärbaren Datenstand
Eine erfolgreiche Testmigration beweist, dass Regeln und Ablauf grundsätzlich funktionieren. Sie hält den Geschäftsbetrieb bis zum Go-live jedoch nicht an. Genau diese zeitliche Lücke muss die Produktivstrategie schließen.
Der einfachste sichere Weg ist ein vollständig neuer Schlusslauf, sofern er in das verfügbare Zeitfenster passt. Ist eine Vorladung notwendig, braucht das Delta einen dokumentierten Ausgangsstand, vier vollständig behandelte Veränderungsarten, eine wiederholbare Ladelogik und einen finalen Quell-Ziel-Abgleich. Dann wird aus „seit dem Test hat sich noch etwas geändert“ ein kontrollierter Bestandteil der ERP-Datenmigration.