NBC release v6.67 – Executive Editorial Briefings ERP-Datenmigration: Stammdaten vor dem Go-live | NBC
ERP · DatenAktualisiert am 20. Juli 2026Lesezeit wird geladen

Datenmigration: Alte Fehler nicht übernehmen

Die Software steht, die Prozesse sind designt, das Team ist geschult – und dann kippt der Go-live, weil Artikelstammdaten doppelt, Kundenkonten uneinheitlich und Projektstrukturen historisch gewachsen sind. Datenmigration ist kein IT-Anhängsel, sondern eines der größten fachlichen Risiken im ERP-Projekt.

Welche Daten verdienen es, in den neuen Betrieb übernommen zu werden?

Projektleitung und Data OwnerFachbereiche vor BereinigungIT und Implementierungspartner
SIGNATURE VISUALData Truth Refinery

Altdaten werden nicht kopiert, sondern fachlich klassifiziert, bereinigt, verantwortet, testweise migriert und freigegeben.

  1. Altdaten
  2. Klassifizieren
  3. Bereinigen
  4. Testmigration
  5. Freigabe

Altdaten werden nicht kopiert, sondern fachlich klassifiziert, bereinigt, verantwortet, testweise migriert und freigegeben.

EXECUTIVE ANSWER

Die Entscheidung in Kürze

Eine ERP-Datenmigration ist kein technischer Kopiervorgang. Sie ist eine fachliche Entscheidung darüber, welche Daten weiterhin gebraucht werden, wer ihre Qualität bestätigt und wie Vollständigkeit sowie Abstimmung vor Go-live nachgewiesen werden.

ENTSCHEIDUNG

Migration ist eine fachliche Freigabeentscheidung über Datenobjekte, Qualität, Eigentümer und Verwendung im Zielprozess.

NACHWEIS

Testmigrationen zeigen Vollständigkeit, Zuordnung, Fehler und fachliche Abnahme vor dem Go-live.

GRENZE

Technische Übertragbarkeit ist nicht gleich fachliche Richtigkeit.

01

Warum ausgerechnet die Stammdaten?

Bewegungsdaten verzeihen Fehler – eine falsche Buchung lässt sich korrigieren. Stammdaten nicht: Artikel, Kunden, Lieferanten, Kostenstellen und Projektstrukturen sind das Skelett des Systems. Jeder Prozess, jede Auswertung, jede Schnittstelle hängt daran. Wer Dubletten und Altlasten migriert, betoniert sie ins neue System ein – und wundert sich, warum die versprochene Transparenz ausbleibt.

02

Die fünf typischen Stammdaten-Fallen

  1. Dubletten: Derselbe Kunde dreimal, leicht unterschiedlich geschrieben. Im Altsystem gelernt zu umgehen – im neuen System zerstört es Auswertungen und Automatisierung.
  2. Tote Datensätze: Artikel, die seit Jahren nicht bewegt wurden, Lieferanten ohne Umsatz. Sie blähen die Migration auf und verlängern jede Testrunde.
  3. Uneinheitliche Strukturen: Jede Abteilung hat eigene Nummernkreise, Bezeichnungslogiken und Projektbäume. Das neue System zwingt zur Entscheidung – besser vorher als im Migrationswochenende.
  4. Feld-Zweckentfremdung: Das Bemerkungsfeld, das in Wahrheit die Liefervereinbarung trägt. Solches Wissen geht bei automatischer Übernahme verloren.
  5. Unklare Verantwortung: Niemand „besitzt" die Kundenstammdaten – also entscheidet niemand, welcher der drei Datensätze der richtige ist.
03

Bereinigung beginnt vor dem Projekt, nicht im Projekt

Der häufigste Planungsfehler: Datenbereinigung als Arbeitspaket kurz vor der Migration. Zu diesem Zeitpunkt fehlt die Zeit, und die Fachbereiche stecken in Schulungen und Tests. Realistisch ist: Bereinigung startet, sobald die Wechselentscheidung fällt – oft ein Jahr vor Go-live. Wer noch in der Entscheidungsphase steckt, hat sogar einen Vorteil: Saubere Daten machen auch das Altsystem besser, egal wie die Entscheidung ausgeht.

Bewährt hat sich die Reihenfolge: Verantwortliche je Datenobjekt benennen, Regeln definieren (was ist ein aktiver Artikel, wie heißt ein Kunde), maschinell vorbereinigen, fachlich nachentscheiden, einfrieren – und ab dann jede Neuanlage nur noch nach neuer Regel.

04

Testmigrationen: dreimal ist Minimum

Eine Migration, die zum ersten Mal am Go-live-Wochenende komplett läuft, ist keine Migration, sondern ein Experiment. Planen Sie mindestens drei vollständige Testläufe mit echten Daten und fachlicher Abnahme: Stimmen Summen, Bestände, offene Posten? Funktionieren die Prozesse mit den migrierten Daten – nicht nur mit den sauberen Demodaten aus der Anbieterpräsentation?

Praxis-Tipp: Lassen Sie sich vom Anbieter früh das Migrationskonzept zeigen – nicht nur das Werkzeug. Wer nur von „Importschnittstellen" spricht, aber nicht nach Ihren Datenverantwortlichen fragt, unterschätzt das Thema.
DECISION LEDGER

Vier Freigaben vor der Migration

Entscheidend ist, welche Voraussetzung für Ihren konkreten Fall noch nicht belegt ist.

PrüffeldLeitfrageBelastbarer NachweisKonsequenz
UmfangWelche Stamm-, Bewegungs- und Historiedaten werden benötigt?Freigegebener Migrationskatalog.Nicht alles ungeprüft übernehmen.
QualitätWelche Regeln gelten für Vollständigkeit und Dubletten?Datenprofil und Bereinigungsregeln.Fachliche Qualität messbar machen.
EigentumWer genehmigt Daten je Domäne?Benannte Data Owner.IT nicht allein freigeben lassen.
AbstimmungWie wird Quelle gegen Ziel geprüft?Probeläufe und fachliche Summenabstimmung.Go-live nur mit Nachweis.

Responsibility Ledger

PERSPEKTIVEData Owner

Qualität und Freigabe fachlich verantworten.

PERSPEKTIVEIT/Partner

Extraktion, Transformation und Ladeprozess liefern.

PERSPEKTIVEProjektleitung

Umfang, Termine und Rest-Risiken steuern.

Warnsignale

  • Migration wird erst nach Konfiguration geplant.
  • Historie wird ohne Nutzungsfall vollständig übernommen.
  • Bereinigung besitzt keinen fachlichen Eigentümer.
  • Der erste vollständige Test findet kurz vor Go-live statt.

WISSEN UND DETAILS

Quellen, Prüfstand und vertiefende Informationen.

Ergänzende Nachweise und Detailfragen sind vollständig am Ende des Artikels gebündelt.

Inhalt und Fortschritt
EXECUTIVE CONCLUSION

Was jetzt entschieden werden sollte

  • EntscheidungMigration ist eine fachliche Freigabeentscheidung über Datenobjekte, Qualität, Eigentümer und Verwendung im Zielprozess.
  • NachweisTestmigrationen zeigen Vollständigkeit, Zuordnung, Fehler und fachliche Abnahme vor dem Go-live.
  • Bewusste GrenzeTechnische Übertragbarkeit ist nicht gleich fachliche Richtigkeit.
15-Minuten-Gespräch