Datenmigration ins neue ERP: Ablauf, Entscheidungen und die Fehler, die teuer werden

Was bei einer ERP-Migration wirklich passiert

Eine Datenmigration ist kein Kopiervorgang. Sie ist eine Übersetzung zwischen zwei Datenmodellen, die sich in Feldern, Schlüsseln und Annahmen unterscheiden — und sie hat einen Stichtag, an dem beide Systeme gleichzeitig eine Wahrheit behaupten.

Für den Fachhandel mit Medizinprodukten kommt hinzu, was nirgends sonst in dieser Dichte vorliegt: Chargen mit Rückverfolgungspflicht, offene Rezepte, Prüfhistorien von Kundengeräten, Belegnummern, die der Steuerberater kennt.

Drei Datenarten, drei Entscheidungen

Der Umschalttag: vier Fragen, schriftlich beantwortet

1. Bleiben die Belegnummern erhalten? Ein Bruch im Nummernkreis ist erklärbar — aber er muss vorher bekannt sein, nicht im Jahresabschluss auffallen.
2. Was passiert mit dem, was am Stichtag halb fertig ist? Ein Auftrag mit zwei von fünf gelieferten Positionen ist der Normalfall, nicht die Ausnahme.
3. Gibt es Parallelbetrieb, und wie lange? Zwei Systeme gleichzeitig zu pflegen ist teuer; es ganz zu vermeiden ist oft teurer.
4. Wer entscheidet bei Konflikten? Wenn beide Systeme denselben Datensatz ändern, braucht es eine Regel, bevor der Fall eintritt.

Der Hybrid-Weg: Übergangsphase statt Sprung

Ein Big-Bang-Umzug über ein Wochenende ist die riskanteste Variante, weil jede Überraschung sofort den Betrieb trifft. Die Alternative ist eine Übergangsphase, in der das Altsystem weiterläuft und Änderungen in das neue System nachfließen.

Das verlangt drei technische Zusagen:

• Herkunft am Datensatz. Jeder übernommene Datensatz trägt den Fremdschlüssel aus dem Altsystem und den Zeitpunkt der letzten Synchronisation. Ohne diese Spur ist kein zweiter Lauf möglich, ohne Dubletten zu erzeugen.
• Idempotenz. Derselbe Datensatz ein zweites Mal importiert überschreibt, statt ein Duplikat anzulegen. Technisch hängt das an einer Eindeutigkeit über Mandant und Fremdschlüssel — nicht an der Disziplin desjenigen, der den Import startet.
• Eine Konfliktregel je Mandant. Üblich sind drei: Altsystem gewinnt (Standard in der Übergangsphase), neues System gewinnt, oder der Konflikt blockiert und wird manuell entschieden.

Wie der Weg aus b-med konkret aussieht

Für Bestandskunden von b-med gibt es diesen Pfad als Werkzeug: ein Exporter läuft beim Kunden, erzeugt ein Paket aus dem Altbestand und überträgt es; danach hält eine Live-Sync-Schnittstelle beide Stände während der Übergangsphase zusammen.

Zwei Eigenschaften dieses Ablaufs sind wichtiger, als sie klingen:

• Der Trockenlauf zählt, ohne zu schreiben. Der Exporter kann zuerst nur zählen, was er finden würde. Diese Zahl ist die Vergleichsgröße für alles Spätere.
• Der Vollimport läuft im Hintergrund, nicht im Web-Request. Ein Paket mit mehreren hundert Megabyte darf nicht an einem Zeitlimit scheitern. Der Fortschritt wird laufend fortgeschrieben, nicht erst am Ende.

Der Fehler, der teuer wird: Felder mit falscher Sichtbarkeit

Das häufigste Schadensmuster ist kein verlorener Datensatz, sondern ein falsch zugeordnetes Feld. Ein Beispiel aus einem echten Mapping: Im Altsystem gab es einen internen Vermerk des Sachbearbeiters. Beim Import landete er im Notizfeld des Belegs — also in einem Feld, das auf Angebot, Auftrag und Rechnung gedruckt werden kann.

Solange niemand dieses Feld auf einem Beleg ausgab, fiel es nicht auf. Es wäre erst in dem Moment aufgefallen, in dem die Notiz auf fünf Belegarten sichtbar wird — und dann bei Empfängern, für die sie nie gedacht war.

Die Regel daraus: Vor jedem Feld-Mapping prüfen, ob das Zielfeld je auf einem Beleg, in einer E-Mail oder im Kundenportal erscheint. Im Zweifel das interne Feld wählen — ein zu Unrecht intern gehaltener Hinweis ist reparabel, ein versendeter nicht.

Vollständigkeit prüfen: der Job-Status beweist gar nichts

Ein Import, der „erfolgreich“ meldet, hat genau das getan: alles verarbeitet, was er sich vorgenommen hat. Ob das dem Altbestand entspricht, ist eine andere Frage.

Der belastbare Weg ist Zählen gegen die Quelle, und zwar mit demselben Filter, den der Import benutzt:

1. Im Altsystem zählen, wie viele Datensätze der Art es gibt.
2. Den Filter des Mappings anwenden — wenn der Import etwa nur eine bestimmte Artikelart übernimmt, muss die Quellzählung denselben Filter tragen.
3. Im Zielsystem zählen.
4. Die Differenz erklären, bevor der Umschalttag steht.

Ohne Schritt 2 entstehen Phantom-Lücken in fünfstelliger Höhe, die keine sind — und echte Lücken verschwinden im Rauschen.

Zeitplan, der in der Praxis hält

• Woche 1–2: Trockenlauf, Zählungen, Feldabgleich. Ergebnis ist eine Liste dessen, was nicht mitkommt.
• Woche 3–4: Erster Vollimport in eine Testumgebung, Stichproben an echten Vorgängen, nicht an Musterdaten.
• Woche 5–6: Zweiter Lauf mit bereinigten Stammdaten, Schulung am eigenen Datenbestand.
• Umschalttag: letzter Lauf, Konfliktregel scharf, Altsystem auf Lesezugriff.

Was diesen Plan verlängert, ist selten die Technik. Es sind die Entscheidungen, die vorher niemand getroffen hat.