DE EN

Praxis Geschäftsentscheidungen

Wie gelingt ERP-Datenmigration ohne Qualitätsverlust?

Schlechte Stammdaten im neuen ERP verstärken alte Probleme. Wie Migration, Bereinigung, Mapping und Stichproben planbar werden, bevor der Go-Live droht.

Ein ERP lebt von Datenqualität. Wer Bestände, Kund*innenstämme und offene Aufträge ungeprüft übernimmt, digitalisiert Inkonsistenzen. Migration ist kein reines IT-Thema und kein Nebenschritt am Go-Live-Wochenende. Sie ist eine gemeinsame Aufgabe von Fachbereichen und Projektteam: Scope festlegen, bereinigen, mappen, testen, freigeben. Wer das erst kurz vor dem Go-Live angeht, riskiert, dass das neue System die alten Datenprobleme nur schneller sichtbar macht.

Warum ungeprüfte Migration Projekte gefährdet

Altsysteme speichern oft Jahrzehnte gewachsene Sonderfälle: Dubletten, tote Artikel, veraltete Adressen, inkonsistente Codes. Im Alltag kaschieren Excel und manuelle Nacharbeit viele dieser Fehler. Im neuen ERP werden sie zur Regel. Disposition arbeitet mit falschen Beständen, Vertrieb mit doppelten Kund*innen, Finanzen mit unklaren Kontierungen. Die Folge ist Misstrauen gegenüber dem System, Parallelpflege und Widerstand nach dem Go-Live.

Datenmigration gehört deshalb zu den klassischen Einführungsfehlern, wenn sie �~irgendwie mitlaufen�S soll. Der Zusammenhang zu Scope, Beteiligung und Planung ist in ERP-Einführung: Typische Fehler vermeiden beschrieben. Umgekehrt gilt: Wer Migration als eigenes Arbeitspaket mit klaren Abnahmekriterien führt, entlastet den Go-Live spürbar.

Welche Daten wirklich zum Start müssen

Nicht alles muss am ersten Tag im neuen System liegen. Sinnvoll ist ein bewusster Scope:

  1. Go-live-kritisch: Entitäten, ohne die der Pilotprozess nicht laufen kann (z. B. Artikel, Kund*innen, offene Aufträge des Kernprozesses).
  2. Nachziehbar: Historie, Archivdaten, selten genutzte Stammdaten, die später importiert oder nur lesend bereitgestellt werden.
  3. Bewusst nicht migrieren: Tote Datensätze, Dubletten, obsolete Varianten. Löschen oder Archivieren vor dem Import spart später mehr Aufwand als jede Nachpflege.

Diese Trennung ist eine Geschäftsentscheidung, keine technische. Fachbereiche kennen, welche Datensätze noch geschäftsrelevant sind. IT kennt, welche Felder und Codes maschinell übertragbar sind. Beides gehört zusammen. Wer �~alles übernehmen�S als Default setzt, maximiert Aufwand und Fehlerrisiko ohne klaren Nutzen.

Welche Schritte Migration planbar machen

Ein belastbarer Migrationsablauf folgt wiederkehrenden Schritten:

  1. Scope festlegen: Welche Entitäten, welche Zeiträume, welche Systeme als Quelle?
  2. Bereinigen: Dubletten, veraltete Artikel, tote Kund*innen vor dem Import klären. Regeln schriftlich festhalten, wer entscheidet.
  3. Mapping dokumentieren: Felder und Codes zwischen Alt- und Neusystem. Sonderfälle und Default-Werte explizit machen.
  4. Testmigration: Mehrfach, mit echten Volumina, nicht nur mit Demo-Ausschnitten.
  5. Stichproben: Nach jedem Testlauf geschäftskritische Datensätze gegenprüfen. Fachbereiche bestätigen, IT dokumentiert Abweichungen.
  6. Rollback-Plan: Was passiert, wenn ein Lauf scheitert? Welche Quelle bleibt führend, bis die Freigabe steht?

Migration ist iterativ. Ein einzelner Export am Go-Live-Tag ist kein Plan, sondern ein Risiko. Zwischen den Läufen bleibt Zeit für Korrekturen am Mapping und an der Quelldatenqualität.

Wer die fachliche Verantwortung trägt

Nuclos bietet Import- und Migrationswerkzeuge. Entscheidend bleibt die fachliche Verantwortung: Fachabteilungen kennen Sonderfälle, die kein generisches Mapping abdeckt. IT kann Felder zuordnen und Läufe steuern. Ob ein Artikel noch aktiv ist, ob zwei Kund*innen dieselbe Firma sind oder ob ein Bestandswert stimmt, entscheidet der Fachbereich. Ohne diese Rollenklarheit entstehen Blame-Games nach dem Go-Live: �~Die Migration war falsch�S versus �~Die Fachdaten waren schon falsch�S.

Hilfreich ist eine benannte Verantwortlichkeit pro Entität (z. B. Artikelstammpflege, Debitoren) plus ein gemeinsames Abnahmeprotokoll nach der letzten Testmigration. So wird Qualität messbar, bevor produktiv umgestellt wird.

Wie Migration zum Prozessrollout passt

Migration parallel zu einer prozessorientierten Einführung entlastet: erst Kernstammdaten für den Pilotprozess, Rest schrittweise. Das passt zu Liefermodellen mit klarem Scope. Nuclos Enterprise liefert produktives ERP in 30 Tagen auf vereinbartem Scope. Umfangreiche Altdatenmigration ist dabei oft ein eigenes Arbeitspaket oder Phase 2, nicht ein stiller Anhang in Woche vier. Wer den Daten-Scope vor Vertragsstart begrenzt, schützt Termin und Festpreis.

Kontext zum Systemkern und typischen Entitäten: ERP-Grundsystem. Wer Einstiege und Scope-Klärung vor dem Gro�xprojekt sucht: Welcher Einstieg in Nuclos passt zu Ihnen?.

Nächste Schritte