Datenmigration im ERP-Projekt: Best Practices für Datenqualität, Strategie und Go-Live

Kernaussagen

• Datenmigration ist in ERP-Projekten kein technischer Nebenschritt, sondern eine zentrale Voraussetzung für einen stabilen Go-Live.
• Ein neues ERP-System verbessert Datenqualität nicht automatisch. Es macht bestehende Datenprobleme häufig nur sichtbarer.
• Ohne belastbare Stammdaten, offene Vorgänge, Bestände, Salden und Zuordnungen kann auch ein leistungsfähiges ERP-System nicht sauber planen, buchen, liefern oder berichten.
• Nicht alle Daten sollten übernommen werden. Historien, inaktive Stammdaten und Altlasten brauchen eine bewusste Entscheidung: migrieren, bereinigen, archivieren oder ausschließen.
• Datenmigration betrifft selten nur ein Altsystem und ein Zielsystem. Verbundene Systeme, Schnittstellen und Übergangsszenarien müssen früh mitgedacht werden.
• ETL, ELT, Staging und Validierung sind keine reinen IT-Details. Sie helfen, Migration nachvollziehbar, testbar und kontrollierbar zu machen.
• Datenqualität ist eine gemeinsame Verantwortung von Fachbereich, IT und Projektleitung. Die IT kann Daten technisch bewegen; ob sie fachlich richtig sind, muss das Unternehmen entscheiden.

Warum Datenmigration in ERP-Projekten oft unterschätzt wird

In ERP-Projekten liegt die Aufmerksamkeit häufig zuerst auf dem neuen System: Welche Funktionen bringt es mit? Wie gut passt es zu den Prozessen? Welche Module werden eingeführt? Was kostet das Projekt? Wann ist der Go-Live? Das ist nachvollziehbar. Die Softwareentscheidung ist sichtbar, teuer und strategisch relevant. Die Datenmigration wirkt dagegen oft wie ein nachgelagerter technischer Schritt: Daten aus dem alten System exportieren, ins neue System importieren, prüfen, fertig. Genau an dieser Stelle entstehen in vielen Projekten Probleme. Denn ein neues ERP-System startet nicht in einem leeren Raum. Es übernimmt Kunden, Lieferanten, Artikel, Preise, Konten, offene Aufträge, Lagerbestände, Salden, Belege, Stücklisten, Projektstrukturen oder Serviceinformationen aus einer bestehenden Systemwelt. Diese Daten sind oft über viele Jahre gewachsen. Sie wurden manuell ergänzt, mehrfach angepasst, zwischen Systemen kopiert, in Excel gepflegt oder durch Sonderprozesse erweitert. Solange das Altsystem läuft, fallen viele Schwächen nicht sofort auf. Mitarbeitende kennen Umgehungslösungen. Fehlende Felder werden mündlich ergänzt. Unklare Artikelnummern werden durch Erfahrung interpretiert. Doppelte Kunden sind bekannt, aber „man weiß ja, welcher der richtige ist“. Im neuen ERP-System funktionieren solche informellen Korrekturen jedoch nicht mehr zuverlässig. Ein typisches Beispiel: Das neue ERP soll die Disposition verbessern. In der Testmigration zeigt sich aber, dass Mindestbestände fehlen, Lieferzeiten nicht gepflegt sind und mehrere Materialgruppen uneinheitlich verwendet werden. Das Problem liegt dann nicht in der Planungslogik des neuen Systems. Das System kann nur nicht sinnvoll planen, wenn die Datengrundlage dafür fehlt. Ähnlich kritisch wird es bei Finanzdaten. Wenn offene Posten, Kontierungen, Kostenstellen oder Salden nicht sauber übernommen werden, betrifft das nicht nur die Migration. Es betrifft Monatsabschlüsse, Mahnläufe, Reporting und das Vertrauen in das neue System. Datenmigration ist deshalb mehr als ein technisches Arbeitspaket kurz vor dem Go-Live. Sie ist ein Realitätscheck: Wie gut sind die vorhandenen Daten wirklich? Welche Daten werden im Zielsystem benötigt? Welche Altlasten sollen nicht übernommen werden? Und wer entscheidet, ob ein Datensatz fachlich korrekt ist? Dass Digitalisierung im Mittelstand kein Selbstläufer ist, zeigen auch aktuelle Analysen. KfW Research berichtet im Digitalisierungsbericht Mittelstand 2025 von nachlassender Dynamik: Nur 30 Prozent der Unternehmen haben zuletzt Digitalisierungsprojekte durchgeführt, zugleich entwickeln sich die Digitalisierungsausgaben rückläufig [1]. Gleichzeitig zeigen die von maximal.digital veröffentlichten Zahlen zur Digitalisierung im Mittelstand, dass Daten zwar strategisch erkannt werden, aber operativ häufig nicht ausreichend verankert sind: 82 Prozent der befragten KMU erachten Datenanalyse als strategisch wichtig, 75 Prozent verfügen jedoch über keine systematische Datenstrategie, 68 Prozent kämpfen mit Datensilos und 58 Prozent haben noch keine funktionierenden Data-Governance-Strukturen etabliert [7]. Für ERP-Projekte ist genau diese Lücke kritisch. Ein neues System kann nur dann sauber planen, buchen, disponieren und berichten, wenn die zugrunde liegenden Daten fachlich belastbar sind. Fehlen Datenstrategie, Verantwortlichkeiten und Governance, wird die Migration schnell zum Punkt, an dem diese Versäumnisse sichtbar werden. Wer eine ERP-Einführung sicher steuern möchte, sollte Datenmigration deshalb nicht als spätes IT-Paket behandeln, sondern als eigenes Projektrisiko mit fachlicher Verantwortung.

Was Datenmigration im ERP-Kontext bedeutet

Datenmigration bedeutet im ERP-Kontext den strukturierten Transfer relevanter Daten aus bestehenden Systemen in ein neues ERP-System. Dazu gehören nicht nur Export und Import, sondern mehrere Schritte: Daten werden ausgewählt, extrahiert, bereinigt, transformiert, validiert und anschließend kontrolliert in das Zielsystem übernommen. Diese Abgrenzung ist wichtig, weil die Begriffe in Projekten häufig vermischt werden. Datenmigration ist in der Regel ein projektbezogener Vorgang. Sie hat ein Zielsystem, definierte Datenobjekte, Testläufe und meist ein Cutover-Datum. Datenintegration meint dagegen den laufenden Datenaustausch zwischen Systemen. Ein CRM übergibt Kundendaten an das ERP. Ein Shop ruft Bestände ab. Ein BI-System erhält regelmäßig Buchungs- oder Umsatzdaten. Datenreplikation beschreibt eine dauerhafte Spiegelung von Datenbeständen, häufig nahezu in Echtzeit. Für ERP-Projekte heißt das: Die Migration muss zwar mit späteren Integrationen zusammengedacht werden, ist aber nicht dasselbe. Es reicht nicht, eine Schnittstelle zu bauen und zu hoffen, dass damit auch die Datenmigration gelöst ist. Ebenso reicht es selten aus, Daten aus dem Altsystem in Excel zu exportieren, manuell zu bereinigen und anschließend über Importvorlagen ins neue ERP zu laden. Bei kleinen, klar abgegrenzten Datenmengen kann das funktionieren. Bei geschäftskritischen ERP-Daten stößt dieser Ansatz schnell an Grenzen: Änderungen sind schwer nachvollziehbar, Prüfregeln fehlen, Fehler werden spät erkannt, und wiederholbare Testmigrationen sind kaum sauber möglich. Das Ziel einer professionellen Datenmigration ist daher nicht nur, dass Daten „irgendwie“ im Zielsystem ankommen. Ziel ist, dass sie vollständig, korrekt, konsistent, nachvollziehbar und fachlich abgenommen im neuen ERP-System nutzbar sind.

Welche Daten im ERP-Projekt betrachtet werden müssen

Nicht alle Daten sind für eine ERP-Migration gleich wichtig. Einige Daten sind unmittelbar geschäftskritisch, andere dienen vor allem der Historie, der Analyse oder der rechtlichen Aufbewahrung. Deshalb beginnt eine gute Migration nicht mit dem technischen Export, sondern mit einer fachlichen Sortierung.

Stammdaten: Grundlage fast aller ERP-Prozesse

Stammdaten sind die Basis vieler Geschäftsprozesse. Dazu gehören Kunden, Lieferanten, Artikel, Materialien, Konten, Kostenstellen, Mitarbeiterdaten oder Anlagenstammdaten. Wenn Stammdaten fehlerhaft sind, wirken sich die Fehler an vielen Stellen aus. Eine falsche Lieferantenadresse betrifft Bestellungen. Eine unvollständige Artikelklassifikation erschwert Disposition und Reporting. Eine doppelte Kundennummer kann zu unklaren Umsätzen, falschen offenen Posten oder Problemen im Mahnwesen führen. Gerade Stammdaten sollten deshalb nicht ungeprüft aus dem Altsystem übernommen werden. Sie brauchen Profiling, Dublettenprüfung, fachliche Bereinigung und klare Verantwortliche. Eine vertiefende Einordnung dazu bietet der Beitrag Stammdatenqualität im ERP verbessern.

Bewegungsdaten: laufende Vorgänge statt Vollhistorie

Bewegungsdaten entstehen durch Geschäftsvorfälle: Angebote, Aufträge, Bestellungen, Lieferscheine, Rechnungen, Buchungen, Produktionsaufträge oder Servicefälle. Bei Bewegungsdaten stellt sich früh die Frage, welche Vorgänge wirklich ins neue ERP müssen. Offene Aufträge, offene Bestellungen oder noch nicht abgeschlossene Produktionsaufträge sind meist migrationsrelevant. Anders sieht es bei lange abgeschlossenen Vorgängen aus. Hier kann eine Archivlösung oft sinnvoller sein als eine vollständige Migration aller historischen Bewegungsdaten.

Offene Posten, Bestände und Salden: kritisch zum Go-Live

Besonders sensibel sind offene Posten, Lagerbestände, Salden und Werte zum Stichtag. Hier geht es nicht nur um Datenübernahme, sondern um einen exakten Schnitt zwischen Alt- und Neusystem. Welche Debitoren- und Kreditorenposten sind offen? Welche Lagerbestände werden mit welcher Menge und welchem Wert übernommen? Welche Sachkontensalden gelten zum Startzeitpunkt? Welche unfertigen Erzeugnisse oder laufenden Projekte müssen berücksichtigt werden? Fehler in diesem Bereich zeigen sich oft sofort nach dem Go-Live: Rechnungen können nicht korrekt verarbeitet werden, Bestände stimmen nicht, Finanzberichte weichen ab, oder offene Vorgänge lassen sich nicht sauber abschließen.

Historische Daten: nicht alles gehört ins neue ERP

Viele Unternehmen möchten möglichst viele Altdaten übernehmen. Das ist verständlich. Niemand möchte später feststellen, dass wichtige Informationen fehlen. Trotzdem ist eine Vollmigration historischer Daten selten automatisch die beste Lösung. Alte Belege, abgeschlossene Aufträge, inaktive Artikel oder lang nicht genutzte Lieferanten erhöhen den Migrationsaufwand, ohne immer einen operativen Nutzen zu bringen. Sie müssen gemappt, geprüft, transformiert und validiert werden. Je größer der Umfang, desto mehr steigt die Komplexität. Deshalb sollte früh entschieden werden, welche historischen Daten aktiv im neuen ERP benötigt werden und welche in ein Archiv, ein BI-System oder eine revisionssichere Ablage gehören.

Konfigurationsdaten und Customizing: nicht immer klassisch migrierbar

Neben Stamm- und Bewegungsdaten gibt es Konfigurationsdaten: Zahlungsbedingungen, Steuerkennzeichen, Buchungskreise, Werke, Lagerorte, Freigaberegeln, Workflows oder Preisfindungslogiken. Microsoft unterscheidet in seinem Dynamics-365-Implementierungsleitfaden ausdrücklich zwischen Konfigurationsdaten, die die Umgebung und Prozesse definieren, und Migrationsdaten wie Kunden, Produkte oder offene Transaktionen [5]. Genau diese Unterscheidung ist auch außerhalb von Dynamics-Projekten hilfreich. Konfigurationsdaten werden nicht immer 1:1 migriert. Häufig werden sie im Zielsystem neu aufgebaut, weil das neue ERP andere Strukturen, Regeln oder Prozesslogiken nutzt. Trotzdem gehören sie in den Migrationsscope, weil sie bestimmen, ob migrierte Daten im Zielsystem korrekt funktionieren. Ein Kundenstamm ist beispielsweise wenig wert, wenn Zahlungsbedingungen, Steuerlogik oder Debitorenkonten nicht passend eingerichtet sind. Ein Artikelstamm funktioniert nicht stabil, wenn Lagerorte, Mengeneinheiten oder Bewertungslogiken nicht sauber abgebildet werden. Die erste Frage in der Datenmigration lautet daher nicht: „Wie bekommen wir alles aus dem alten System heraus?“ Sie lautet: Welche Daten brauchen wir im neuen ERP, in welcher Qualität, zu welchem Zeitpunkt und mit welcher fachlichen Verantwortung?

Warum Datenqualität vor der Migration beginnt

Ein häufiger Irrtum in ERP-Projekten lautet: Wenn das neue System eingeführt ist, werden auch die Daten besser. Das stimmt nur selten. Ein neues ERP-System kann bessere Datenstrukturen, Pflichtfelder, Validierungsregeln und Prozesse mitbringen. Es kann aber keine fehlende Datenverantwortung ersetzen. Wenn Kunden doppelt angelegt sind, Artikelstämme uneinheitlich gepflegt wurden, Bestände nicht stimmen oder Kostenstellen historisch gewachsen sind, dann verschwinden diese Probleme nicht durch die Migration. Sie werden im neuen System oft nur sichtbarer. Gerade deshalb sollte Datenqualität nicht erst während der finalen Migration geprüft werden. Wer erst kurz vor dem Go-Live feststellt, dass Pflichtfelder fehlen, Dubletten unklar sind oder Bewegungsdaten nicht zu Stammdaten passen, verliert wertvolle Zeit. Dann müssen fachliche Entscheidungen unter Druck getroffen werden: Welcher Kundensatz ist führend? Welche alte Artikelnummer bleibt erhalten? Welche offenen Vorgänge werden übernommen? Welche historischen Daten werden archiviert? Datenqualität ist dabei kein abstrakter Anspruch. Sie lässt sich prüfen. Für ERP-Migrationen sind vor allem sechs Dimensionen relevant: Vollständigkeit, Genauigkeit, Konsistenz, Einzigartigkeit, Aktualität und Gültigkeit. Diese Dimensionen werden auch in gängigen Datenqualitätsmodellen und Frameworks verwendet, etwa im Government Data Quality Framework und im ISO/IEC-25012-Modell für Datenqualität [3, 4].

Vollständigkeit: Sind alle notwendigen Felder befüllt?

Viele Zielsysteme verlangen Informationen, die im Altsystem optional waren oder gar nicht gepflegt wurden. Das betrifft zum Beispiel E-Mail-Adressen, Steuer-IDs, IBANs, Mengeneinheiten, Artikelklassifikationen, Zahlungsbedingungen oder Pflichtattribute für die Disposition. Ein fehlendes Feld wirkt auf den ersten Blick harmlos. Im ERP-Alltag kann es aber Prozesse blockieren: Eine Bestellung lässt sich nicht erzeugen, ein Kunde kann nicht fakturiert werden, ein Artikel kann nicht disponiert werden, weil eine Planungsinformation fehlt.

Genauigkeit: Stimmen die Daten mit der Realität überein?

Nicht jede formal vollständige Information ist auch richtig. Eine Adresse kann befüllt, aber veraltet sein. Ein Lieferant kann aktiv erscheinen, obwohl seit Jahren keine Bestellung mehr erfolgt ist. Ein Artikel kann mit einem Preis geführt werden, der längst nicht mehr verwendet wird. Gerade hier reicht eine rein technische Prüfung nicht aus. Ob eine Adresse, ein Preis, ein Lieferant oder eine Kontierung fachlich korrekt ist, muss der zuständige Fachbereich beurteilen.

Konsistenz: Passen Daten über Tabellen und Systeme hinweg zusammen?

ERP-Daten stehen selten isoliert. Ein Auftrag verweist auf einen Kunden, eine Rechnung auf einen offenen Posten, ein Lagerbestand auf einen Artikel, eine Buchung auf ein Konto oder eine Kostenstelle. Wenn solche Beziehungen nicht stimmen, entstehen Fehler, die nicht immer sofort sichtbar sind. Ein klassisches Problem: Bewegungsdaten enthalten Referenzen auf Stammdatensätze, die bereinigt, gelöscht oder im Zielsystem anders strukturiert wurden. Dann ist die Migration technisch vielleicht erfolgreich, aber fachlich unbrauchbar.

Einzigartigkeit: Gibt es Dubletten?

Dubletten sind in ERP-Projekten besonders tückisch. Zwei Kunden mit leicht abweichender Schreibweise, mehrere Lieferantensätze für denselben Partner oder doppelte Artikelnummern aus unterschiedlichen Standorten wirken im Altsystem oft beherrschbar. Im neuen ERP können sie Reporting, offene Posten, Konditionen, Mahnläufe und Berechtigungen durcheinanderbringen. Dublettenbereinigung sollte deshalb nicht erst im neuen System stattfinden. Sie gehört in die Vorbereitung, weil dabei fachliche Entscheidungen nötig sind: Welcher Datensatz bleibt? Welche Historie wird zugeordnet? Welche Nummernlogik gilt künftig?

Aktualität: Werden veraltete Daten wirklich noch gebraucht?

Nicht jeder Datensatz, der existiert, ist auch migrationswürdig. Inaktive Lieferanten, alte Kunden, stillgelegte Artikel, abgelöste Kostenstellen oder abgeschlossene Projekte erhöhen den Migrationsumfang. Sie schaffen aber nicht automatisch Mehrwert. Aktualität ist deshalb eng mit dem Migrationsscope verbunden. Unternehmen sollten prüfen, welche Daten operativ gebraucht werden, welche rechtlich aufbewahrt werden müssen und welche besser archiviert als aktiv migriert werden.

Gültigkeit: Entsprechen Daten definierten Formaten?

IBANs, Postleitzahlen, Datumsformate, Steuernummern, E-Mail-Adressen, Mengeneinheiten oder Währungscodes müssen im Zielsystem bestimmten Regeln entsprechen. Was im Altsystem als Freitext funktioniert hat, kann im neuen ERP an Validierungsregeln scheitern. Diese Prüfung ist vergleichsweise gut automatisierbar. Sie sollte früh erfolgen, weil Formatprobleme in großen Datenmengen sonst erst beim Import sichtbar werden. Die wichtigste Konsequenz lautet: Datenqualität muss vor der Migration messbar gemacht werden. Nicht als perfekte akademische Übung, sondern als pragmatische Standortbestimmung. Welche Daten sind kritisch? Wo fehlen Pflichtinformationen? Welche Dubletten müssen bereinigt werden? Welche Datenbereiche sind gut genug für eine Testmigration? Und wo braucht es fachliche Entscheidungen, bevor überhaupt technisch migriert werden kann?

Verbundene Systeme und Übergangsszenarien mitdenken

ERP-Datenmigration wird oft als Bewegung von A nach B verstanden: vom alten ERP ins neue ERP. In der Praxis ist es selten so einfach. Viele Unternehmen arbeiten mit einer gewachsenen Systemlandschaft. Neben dem ERP gibt es CRM-Systeme, Onlineshops, DMS-Lösungen, BI-Tools, MES- oder WMS-Systeme, HR-Anwendungen, Finanzsysteme, Excel-Listen, Access-Datenbanken oder individuell entwickelte Anwendungen. Manche dieser Systeme liefern Daten an das ERP. Andere empfangen Daten vom ERP. Wieder andere werden im Projekt abgelöst, aber nicht sofort. Bitkom weist in der Data-Economy-Studie 2025 darauf hin, dass Unternehmen zwar über wertvolle Daten verfügen, diese aber häufig nicht einfach wirtschaftlich nutzbar machen können [2]. Für ERP-Migrationen ist das ein vertrautes Muster: Daten sind vorhanden, aber über Systeme, Formate, Verantwortlichkeiten und Prozesse verteilt. Die von maximal.digital berichteten Zahlen zu Datensilos und fehlender Governance im Mittelstand passen genau in dieses Bild: Wenn Daten nicht integriert, Verantwortlichkeiten unklar und Qualitätsregeln nicht etabliert sind, wird der Wechsel auf ein neues ERP-System deutlich schwieriger [7]. Deshalb reicht es nicht, nur das Quell- und Zielsystem zu betrachten. Vor einer Migration muss klar sein, welche Systeme betroffen sind und wie sie während der Übergangsphase zusammenspielen. Ein Beispiel: Ein Unternehmen führt ein neues ERP ein, der bestehende Onlineshop bleibt aber zunächst erhalten. Dann muss geklärt werden, welches System künftig führend für Artikel, Preise, Verfügbarkeiten und Kundendaten ist. Werden Artikel im ERP gepflegt und an den Shop übergeben? Oder bleibt der Shop zunächst führend für Produktinformationen? Wie werden Bestände synchronisiert? Was passiert mit offenen Shop-Bestellungen zum Cutover-Zeitpunkt? Solche Fragen wirken technisch. Tatsächlich sind sie organisatorisch und fachlich. Denn ohne klare Führungslogik entstehen doppelte Pflege, widersprüchliche Datenstände oder Prozessbrüche. Ein Vertriebsmitarbeiter sieht dann einen anderen Kundenstatus als der Service. Der Shop zeigt Bestände, die im ERP nicht mehr verfügbar sind. Ein BI-Report greift noch auf Altdaten zu, während die operative Steuerung bereits im neuen System läuft. Übergangsszenarien sind deshalb ein eigener Risikobereich der Datenmigration. Unternehmen sollten früh klären:

• Welche Systeme liefern migrationsrelevante Daten?
• Welche Systeme bleiben nach dem Go-Live angebunden?
• Wo liegt während der Übergangsphase die führende Datenquelle?
• Welche Daten werden einmalig migriert, welche laufend synchronisiert?
• Welche Reports, Schnittstellen und Nebenprozesse müssen angepasst werden?
• Welche Daten dürfen nach dem Cutover im Altsystem nicht mehr verändert werden?

Gerade bei phasenweisen Migrationen oder Parallelbetrieb wird diese Klärung entscheidend. Sonst ist zwar das neue ERP produktiv, aber die umgebende Systemlandschaft arbeitet weiter nach alten Annahmen.

Nicht alles migrieren: Scope-Entscheidungen bewusst treffen

Eine gute Datenmigration übernimmt nicht möglichst viele Daten. Sie übernimmt die richtigen Daten in der richtigen Qualität. Das klingt selbstverständlich, wird in Projekten aber oft zu spät geklärt. Fachbereiche möchten auf Nummer sicher gehen und möglichst viel Historie behalten. IT und Projektleitung wollen Komplexität reduzieren. Finance braucht prüfbare Salden und offene Posten. Vertrieb und Service möchten alte Kundeninformationen weiterhin einsehen können. Management erwartet vergleichbare Auswertungen. All diese Anliegen sind nachvollziehbar. Sie führen aber nicht automatisch zu einer sinnvollen Vollmigration. Je mehr Daten übernommen werden, desto größer werden Mapping-Aufwand, Testbedarf, Fehlerpotenzial und Abstimmungsaufwand. Alte Daten müssen nicht nur exportiert werden. Sie müssen in das neue Datenmodell passen, mit Stammdaten verknüpft, validiert und fachlich geprüft werden. Bei abgeschlossenen Vorgängen ist der Nutzen dafür häufig begrenzt. Deshalb sollte der Migrationsscope entlang konkreter Fragen entschieden werden.

Welche Daten werden ab dem ersten produktiven Tag benötigt?

Offene Aufträge, offene Bestellungen, aktuelle Kunden und Lieferanten, aktive Artikel, Bestände, Salden und offene Posten sind meist zwingend erforderlich. Ohne diese Daten können operative Prozesse nicht stabil starten.

Welche Daten müssen aufbewahrt, aber nicht aktiv migriert werden?

Alte Rechnungen, abgeschlossene Aufträge, historische Buchungen oder Projektdokumentationen können rechtlich oder fachlich relevant bleiben. Das bedeutet aber nicht automatisch, dass sie im neuen ERP aktiv geführt werden müssen. Häufig reicht eine Archivlösung oder ein lesender Zugriff auf Altdaten.

Welche Daten werden für Reporting und Analyse gebraucht?

Manche historischen Daten sind für Umsatzvergleiche, Kundenanalysen, Produktlebenszyklen oder Controlling wichtig. Auch hier stellt sich die Frage, ob sie ins ERP gehören oder besser in ein BI- oder Data-Warehouse-Szenario überführt werden.

Welche Altlasten sollten bewusst nicht übernommen werden?

Inaktive Artikel, alte Preislisten, ungenutzte Lieferanten, doppelte Kunden, veraltete Kostenstellen oder historisch gewachsene Sonderfelder können das Zielsystem unnötig belasten. Eine Migration ist auch eine Gelegenheit, solche Altlasten nicht weiter mitzuschleppen. Eine einfache Entscheidungslogik kann helfen:

Datenbereich	Typische Empfehlung	Begründung
Aktive Kunden und Lieferanten	migrieren	Grundlage für laufende Geschäftsprozesse
Aktive Artikel und Materialien	migrieren	relevant für Einkauf, Lager, Produktion und Vertrieb
Offene Aufträge und Bestellungen	migrieren	notwendig für operative Kontinuität
Bestände, offene Posten und Salden	migrieren	kritisch für Go-Live und Abschlussfähigkeit
Alte abgeschlossene Belege	prüfen	häufig reicht Archiv oder Lesesystem
Inaktive Artikel und Lieferanten	selektiv migrieren	sonst unnötige Komplexität
Historische Buchungen	oft archivieren oder aggregieren	Zielsystem nicht überfrachten
Alte Sonderfelder	kritisch prüfen	meist Hinweis auf frühere Workarounds

Der entscheidende Punkt: „Nicht migrieren“ bedeutet nicht „löschen“. Es bedeutet, bewusst zu entscheiden, wo Daten künftig liegen sollen und wie sie zugänglich bleiben. Ein gut geplantes Archiv kann für alte Belege sinnvoller sein als eine technisch aufwendige Migration in das neue ERP.

Migrationsstrategien: Big Bang, phasenweise Migration oder Parallelbetrieb?

Die Migrationsstrategie bestimmt, wie der Übergang vom alten auf das neue System organisiert wird. Sie ist keine reine IT-Entscheidung. Sie betrifft Risiko, Betriebsunterbrechung, Ressourcen, Testaufwand, Schulung, Schnittstellen und fachliche Abnahme. In der Praxis gibt es drei Grundmuster: Big Bang, phasenweise Migration und Parallelbetrieb.

Big Bang: klarer Schnitt mit hohem Anspruch an Vorbereitung

Beim Big Bang wird zu einem definierten Stichtag vollständig auf das neue ERP-System gewechselt. Das Altsystem wird eingefroren oder abgeschaltet, die relevanten Daten werden final migriert, und ab dem Go-Live arbeitet das Unternehmen im Zielsystem. Der Vorteil liegt auf der Hand: Es gibt einen klaren Schnitt. Die Übergangsphase ist kurz, doppelte Pflege wird begrenzt, und die Organisation muss nicht über längere Zeit mit zwei Systemlogiken arbeiten. Der Nachteil ist ebenso klar: Fehler wirken sofort breit. Wenn Stammdaten fehlen, offene Posten nicht stimmen oder Bestände falsch übernommen wurden, betrifft das unmittelbar alle betroffenen Bereiche. Ein Big Bang braucht deshalb eine hohe Testreife, stabile Datenqualität, klare Cutover-Pläne und eine Organisation, die Entscheidungen schnell treffen kann. Geeignet ist dieser Ansatz vor allem bei überschaubaren Systemlandschaften, klaren Prozessen, begrenztem Datenumfang und hoher Vorbereitungssicherheit. Wer dagegen viele Standorte, mehrere Gesellschaften, komplexe Schnittstellen oder unsichere Datenqualität hat, sollte den Big Bang sehr sorgfältig prüfen.

Phasenweise Migration: Risiken begrenzen, Übergänge steuern

Bei einer phasenweisen Migration wird nicht alles auf einmal umgestellt. Die Migration erfolgt in Wellen, zum Beispiel nach Standorten, Gesellschaften, Modulen, Prozessbereichen oder Datenobjekten. Der Vorteil: Fehler bleiben eher begrenzt. Eine Gesellschaft, ein Standort oder ein Prozessbereich kann migriert werden, während andere Bereiche noch im Altsystem arbeiten. Das schafft Lernkurven und reduziert das Risiko eines unternehmensweiten Fehlstarts. Der Preis dafür ist Übergangskomplexität. Wenn Teile der Organisation im alten und andere im neuen System arbeiten, müssen Schnittstellen, Stammdatenführung, Reporting und Verantwortlichkeiten besonders sauber geregelt sein. Sonst entstehen Medienbrüche und widersprüchliche Datenstände. Phasenweise Migration eignet sich häufig für Unternehmen mit mehreren Standorten, unterschiedlichen Prozessdomänen, komplexen Systemlandschaften oder begrenzter interner Projektkapazität. Sie verlangt aber eine gute Übergangsarchitektur.

Parallelbetrieb: maximale Sicherheit, hoher Aufwand

Beim Parallelbetrieb laufen Alt- und Neusystem für eine gewisse Zeit nebeneinander. Daten oder Vorgänge werden doppelt geführt oder miteinander abgeglichen. Dadurch lassen sich Abweichungen früh erkennen. Das kann sinnvoll sein, wenn Prozesse besonders kritisch sind, regulatorische Anforderungen bestehen oder die Datenlage noch nicht ausreichend sicher ist. Der Parallelbetrieb gibt Sicherheit, weil Ergebnisse aus beiden Systemen verglichen werden können. Er ist aber aufwendig. Doppelte Pflege bindet Ressourcen. Mitarbeitende müssen zwei Systemlogiken verstehen. Schnittstellen und Auswertungen werden komplexer. Außerdem besteht das Risiko, dass der Parallelbetrieb länger dauert als geplant, weil niemand den endgültigen Schnitt verantworten möchte. Der Parallelbetrieb sollte deshalb nicht als bequeme Absicherung missverstanden werden. Er braucht klare Dauer, klare Vergleichskriterien und ein definiertes Ende.

Welche Strategie passt?

Es gibt keine pauschal beste Migrationsstrategie. Entscheidend sind Fragen wie:

• Wie gut ist die Datenqualität bereits geprüft?
• Wie komplex ist die Systemlandschaft?
• Wie viele Standorte, Gesellschaften oder Prozessbereiche sind betroffen?
• Welche Ausfallrisiken kann das Unternehmen tragen?
• Wie viel Doppelpflege ist realistisch leistbar?
• Welche Schnittstellen müssen während der Übergangszeit funktionieren?
• Wie belastbar sind Testmigration und fachliche Abnahme?

Die Strategie sollte aus der Risikobetrachtung entstehen, nicht aus Wunschdenken. Ein Big Bang kann richtig sein, wenn Vorbereitung, Datenqualität und Organisation passen. Eine phasenweise Migration kann klüger sein, wenn Abhängigkeiten komplex sind. Ein Parallelbetrieb kann sinnvoll sein, wenn Sicherheit wichtiger ist als Geschwindigkeit. Wichtig ist nur: Die Entscheidung muss früh fallen. Denn Migrationsstrategie, Datenbereinigung, Testplanung, Schnittstellenkonzept und Cutover hängen eng zusammen.

ETL, ELT und Staging: Warum die technische Architektur auch fachlich relevant ist

Wer sich zum ersten Mal mit ERP-Datenmigration beschäftigt, stößt schnell auf Begriffe wie ETL, ELT, Staging Area, Mapping, Validierung oder Cutover. Das klingt zunächst technisch. Für Geschäftsführer, Projektleiter oder Fachverantwortliche ist aber nicht entscheidend, jedes Tool im Detail zu kennen. Wichtiger ist das Grundprinzip: Eine Migration muss nachvollziehbar, wiederholbar und prüfbar sein. Denn genau daran scheitern viele pragmatische Migrationsansätze. Daten werden exportiert, in Tabellen bearbeitet, in Importvorlagen übertragen und anschließend ins Zielsystem geladen. Wenn später Fehler auftreten, ist oft unklar, an welcher Stelle sie entstanden sind. War die Quelle bereits fehlerhaft? Wurde beim Export ein Format verändert? Wurde im Mapping ein Feld falsch zugeordnet? Hat der Import Datensätze abgelehnt? Oder wurde nachträglich manuell korrigiert? Eine professionelle Migrationsarchitektur trennt diese Schritte. Sie macht sichtbar, was aus dem Altsystem kommt, was bereinigt wurde, welche Transformationen vorgenommen wurden und welche Daten am Ende tatsächlich im Zielsystem angekommen sind.

ETL: transformieren vor dem Laden

ETL steht für Extract, Transform, Load. Daten werden also zuerst aus dem Quellsystem extrahiert, anschließend bereinigt und transformiert und erst danach in das Zielsystem geladen. Dieser Ansatz ist besonders naheliegend, wenn das neue ERP-System möglichst sauber gehalten werden soll. Fehlerhafte Rohdaten werden nicht direkt ins Zielsystem übernommen. Stattdessen werden sie vorher geprüft, angepasst und in die Zielstruktur gebracht. In ERP-Projekten ist ETL häufig sinnvoll, wenn klare Migrationsregeln bestehen: Ein altes Datumsformat wird in ein neues Format überführt. Kundennummern werden angepasst. Materialgruppen werden harmonisiert. Pflichtfelder werden ergänzt. Dubletten werden bereinigt. Erst wenn diese Schritte abgeschlossen sind, werden die Daten geladen. Der Vorteil liegt in der Kontrolle. Der Nachteil: Die Transformationslogik muss sauber dokumentiert werden. Sonst entsteht eine technische Blackbox, in der zwar Daten verändert werden, aber niemand später nachvollziehen kann, warum.

ELT: laden, dann transformieren

ELT steht für Extract, Load, Transform. Hier werden Rohdaten zunächst in eine Ziel- oder Datenplattform geladen und dort transformiert. Dieser Ansatz ist in modernen Cloud- und Datenplattformen verbreitet, weil diese Systeme große Datenmengen verarbeiten und Transformationen direkt in der Plattform ausführen können. Für ERP-Projekte ist ELT vor allem dann interessant, wenn Daten nicht nur ins ERP, sondern auch in eine Analyse-, Reporting- oder Archivumgebung überführt werden. Rohdaten bleiben länger verfügbar. Transformationen können versioniert und schrittweise nachvollzogen werden. Das klingt attraktiv, ist aber nicht automatisch besser. Wenn Rohdaten in Zielumgebungen geladen werden, braucht es klare Zugriffsrechte, Datenbereiche und Verantwortlichkeiten. Außerdem muss sichergestellt sein, dass das operative ERP nicht mit ungeprüften Daten belastet wird.

Hybrid: pragmatisch statt dogmatisch

In vielen ERP-Projekten ist ein hybrider Ansatz sinnvoll. Kritische Bereinigungen und Prüfungen erfolgen vor dem Laden. Andere Transformationen, etwa für Reporting oder Archivierung, können später in einer Datenplattform stattfinden. Die Unterscheidung ist deshalb weniger dogmatisch, als sie auf den ersten Blick wirkt. Wichtig ist nicht, ob ein Projekt „ETL“ oder „ELT“ als Schlagwort verwendet. Entscheidend ist, ob die Datenstrecke kontrolliert ist: Sind Rohdaten gesichert? Sind Transformationen dokumentiert? Sind Fehler nachvollziehbar? Kann ein Testlauf wiederholt werden? Gibt es Abnahmekriterien?

Staging Area: die Sicherheitszone der Migration

Eine Staging Area ist eine kontrollierte Zwischenschicht zwischen Quellsystem und Zielsystem. Dort werden Daten nicht sofort produktiv genutzt, sondern zunächst abgelegt, geprüft, bereinigt und gemappt. Man kann sich die Staging Area als Arbeitsbereich vorstellen. Dort liegen Rohdaten aus dem Altsystem, bereinigte Daten, transformierte Daten und Validierungsergebnisse getrennt voneinander. Das Zielsystem wird nicht direkt aus einem unkontrollierten Export befüllt, sondern aus einem geprüften Datenstand. Das hat mehrere Vorteile:

• Fehler lassen sich besser lokalisieren.
• Testmigrationen können wiederholt werden.
• Änderungen bleiben nachvollziehbar.
• Rohdaten bleiben als Referenz erhalten.
• Fachbereiche können Daten vor dem finalen Load prüfen.
• Der Go-Live basiert auf einem validierten Datenstand.

Gerade bei ERP-Projekten ist diese Trennung wichtig. Denn hier geht es nicht nur um technische Datenübernahme, sondern um betriebliche Handlungsfähigkeit nach dem Go-Live. Ein fehlerhafter Kundenstamm, falsche Bestände oder unvollständige offene Posten sind keine abstrakten Datenprobleme. Sie wirken direkt in Vertrieb, Einkauf, Produktion, Lager, Finance und Service.

Best Practices für eine sichere ERP-Datenmigration

Eine belastbare Datenmigration entsteht nicht durch einen einzelnen Importlauf. Sie entsteht durch Vorbereitung, klare Entscheidungen, wiederholbare Tests und fachliche Abnahme. Die folgenden Best Practices sind deshalb weniger als Checkliste für die IT zu verstehen, sondern als gemeinsame Projektlogik für Fachbereiche, IT und Projektleitung. SAP nennt in einem ERP-Migrationsleitfaden unter anderem die Bewertung vorhandener Daten, sorgfältiges Feld-Mapping, Data Governance und einen strengen Validierungsprozess als zentrale Best Practices [6]. Diese Punkte decken sich mit vielen Projekterfahrungen aus ERP-Einführungen im Mittelstand.

1. Datenprofiling früh starten

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Welche Daten liegen in welchen Systemen? Wie viele Kunden, Lieferanten, Artikel, Belege, Bestände und offene Posten gibt es? Welche Felder sind leer? Wo gibt es Dubletten? Welche Datenformate weichen voneinander ab? Dieses Profiling sollte nicht erst beginnen, wenn das Zielsystem bereits konfiguriert ist. Es gehört in die frühe Projektphase, teilweise sogar schon in die Vorbereitung der ERP-Auswahl. Denn Datenumfang und Datenqualität beeinflussen Projektaufwand, Zeitplan, Migrationsstrategie und Anbieterbewertung.

2. Datenobjekte priorisieren

Nicht alle Daten haben dieselbe Bedeutung für den Go-Live. Stammdaten, offene Vorgänge, Bestände, Salden und offene Posten sind meist deutlich kritischer als abgeschlossene Historien. Eine sinnvolle Priorisierung könnte so aussehen:

• zuerst geschäftskritische Stammdaten,
• dann offene operative Vorgänge,
• anschließend Bestände, Salden und offene Posten,
• danach relevante Historien,
• zuletzt Archiv- und Auswertungsdaten.

Diese Reihenfolge ist nicht in jedem Projekt identisch. Sie zwingt aber zu einer wichtigen Frage: Welche Daten müssen am ersten produktiven Tag wirklich funktionieren?

3. Den Migrationsscope verbindlich festlegen

Viele Diskussionen in Migrationsprojekten entstehen, weil nicht klar entschieden wurde, was übernommen wird und was nicht. Deshalb braucht es einen verbindlichen Scope. Dazu gehören Entscheidungen wie:

• Welche Datenobjekte werden migriert?
• Welche historischen Zeiträume werden übernommen?
• Welche Daten werden archiviert?
• Welche Daten werden bereinigt?
• Welche Daten werden bewusst ausgeschlossen?
• Welche Systeme bleiben als Lesearchiv verfügbar?

Diese Entscheidungen sollten nicht informell in Workshops verschwinden. Sie müssen dokumentiert und von den Verantwortlichen getragen werden. Sonst wird der Scope im Projektverlauf immer größer.

4. Verbundene Systeme erfassen

Vor der technischen Umsetzung sollte die Systemlandschaft sichtbar sein. Welche Systeme liefern Daten? Welche empfangen Daten? Welche Schnittstellen bleiben bestehen? Welche werden ersetzt? Welche Reports greifen auf welche Datenquellen zu? Gerade in gewachsenen mittelständischen IT-Landschaften liegen wichtige Informationen nicht nur im ERP. CRM, Shop, DMS, BI, MES, WMS, HR-Systeme oder Excel-Nebenprozesse können migrationsrelevant sein. Werden sie nicht berücksichtigt, entstehen nach dem Go-Live Lücken. Ein einfaches Systembild mit Datenflüssen reicht oft schon aus, um kritische Abhängigkeiten sichtbar zu machen.

5. Data Owner benennen

Datenmigration braucht fachliche Eigentümer. Wer entscheidet, ob ein Kundensatz richtig ist? Wer bewertet, ob ein Artikel aktiv bleibt? Wer klärt, welche Kostenstelle künftig verwendet wird? Wer gibt offene Posten fachlich frei? Ohne Data Owner werden diese Entscheidungen oft an die IT delegiert. Das ist riskant. Die IT kann prüfen, ob ein Feld gefüllt ist. Sie kann aber nicht immer entscheiden, ob der Wert fachlich korrekt ist. Data Owner sollten deshalb je Datenbereich benannt werden: etwa für Kunden, Lieferanten, Artikel, Finance, Lager, Produktion oder Service.

6. Mapping dokumentieren

Ein Mapping-Dokument beschreibt, wie Daten aus dem Altsystem in das Zielsystem übertragen werden. Es hält fest, welches Quellfeld welchem Zielfeld entspricht, welche Transformationen nötig sind, welche Pflichtfelder ergänzt werden müssen und welche Regeln gelten. Das klingt administrativ, ist aber zentral. Ohne Mapping-Dokument wird die Migration schwer prüfbar. Später weiß niemand mehr, warum ein Feld anders befüllt wurde, warum bestimmte Datensätze ausgeschlossen wurden oder welche Regel für eine Transformation galt. Ein gutes Mapping-Dokument enthält mindestens:

• Quellsystem und Quellfeld,
• Zielfeld,
• Datentyp,
• Pflichtfeldstatus,
• Transformationsregel,
• fachliche Verantwortung,
• Test- und Validierungsregel,
• offene Klärpunkte.

7. Daten vorab bereinigen

Datenbereinigung sollte nicht auf das Zielsystem verschoben werden. Dubletten, veraltete Datensätze, fehlende Pflichtfelder, uneinheitliche Formate und falsche Zuordnungen sollten möglichst vor der Migration geklärt werden. Das bedeutet nicht, dass jedes historische Detail perfekt sein muss. Es bedeutet aber, dass geschäftskritische Datenbereiche einen definierten Qualitätsstand erreichen müssen, bevor sie ins neue ERP übernommen werden. Besonders wichtig sind:

• aktive Kunden und Lieferanten,
• Artikel und Materialien,
• offene Vorgänge,
• Bestände,
• Konten und Kostenstellen,
• steuer- und finanzrelevante Daten,
• Daten für Planung und Disposition.

8. Testmigrationen realistisch planen

Eine Testmigration mit wenigen idealen Beispieldatensätzen ist wenig wert. Sie zeigt, ob der Import grundsätzlich funktioniert. Sie zeigt aber nicht, ob das Projekt mit echten Datenmengen, echten Fehlern und echten Sonderfällen umgehen kann. Testmigrationen sollten deshalb realistische Daten enthalten. Dazu gehören saubere Datensätze, problematische Datensätze, Grenzfälle, alte Strukturen und typische Sonderlogiken. Wichtig ist auch: Eine Testmigration ist kein einmaliges Ereignis. Meist braucht es mehrere Läufe. Der erste Lauf zeigt Fehler. Der zweite prüft Korrekturen. Weitere Läufe stabilisieren Mapping, Validierung und Cutover-Planung.

9. Validierungsregeln definieren

Nach einer Migration reicht es nicht, zu prüfen, ob der Import technisch abgeschlossen wurde. Es muss geprüft werden, ob die Daten vollständig und fachlich plausibel angekommen sind. Typische Validierungen sind:

• Anzahl Datensätze Quelle gegen Ziel,
• Summenvergleiche bei Beträgen, Beständen oder Salden,
• Pflichtfeldprüfung,
• Prüfung referenzieller Beziehungen,
• Stichproben durch Fachbereiche,
• Plausibilitätsprüfungen bei Preisen, Mengen, Währungen oder Datumswerten,
• Fehler- und Abweichungslisten.

Validierung ist der Punkt, an dem sich technische Migration und fachliche Abnahme treffen. Ohne sie bleibt unklar, ob das Zielsystem wirklich mit belastbaren Daten startet.

10. Cutover mit Go/No-Go-Kriterien planen

Der Cutover ist der Übergang in den produktiven Betrieb. Er braucht mehr als einen Termin im Projektplan. Geklärt werden müssen unter anderem:

• Wann wird das Altsystem eingefroren?
• Welche Daten dürfen nach dem Freeze noch verändert werden?
• Wann erfolgt der finale Export?
• Wie lange dauert der Load?
• Wer prüft welche Daten?
• Welche Fehler sind akzeptabel?
• Wann wird gestoppt?
• Welche Rückfalloption gibt es?
• Wer entscheidet final über Go oder No-Go?

Ein Go-Live sollte nicht auf Hoffnung beruhen, sondern auf definierten Prüfungen.

11. Fachliche Abnahme ernst nehmen

Technisch erfolgreich heißt nicht fachlich korrekt. Ein Datensatz kann importiert werden und trotzdem falsch sein. Eine Summe kann stimmen, obwohl Einzelzuordnungen falsch sind. Ein Kunde kann angelegt sein, aber mit falscher Zahlungsbedingung. Ein Artikel kann vorhanden sein, aber ohne relevante Dispositionsdaten. Deshalb braucht es eine fachliche Abnahme durch Menschen, die die Prozesse und Daten verstehen. Das können Key User, Fachbereichsverantwortliche oder Business Validatoren sein. Wichtig ist, dass sie nicht nur bestätigen, dass Daten vorhanden sind. Sie müssen prüfen, ob typische Geschäftsfälle im neuen ERP funktionieren.

Rollen und Governance: Wer entscheidet über Daten?

Hinzu kommt ein Ressourcenproblem. Nach den von dir eingebrachten Lünendonk-Zahlen streben 72 Prozent der Anwenderunternehmen den Wandel zu einer datengetriebenen Organisation an, zugleich geben 69 Prozent an, dass ihnen gerade in den Bereichen Data & Analytics die notwendigen Mitarbeitenden fehlen [8]. Für ERP-Migrationen bedeutet das: Der Wille zu besseren Daten ist oft vorhanden, aber die operative Verantwortung bleibt im Projektalltag unklar oder personell unterbesetzt. In der Praxis haben sich mehrere Rollen bewährt:

Rolle	Verantwortung
Data Owner	entscheidet über Datenumfang, fachliche Korrektheit und Abnahme
IT- oder Migrationsverantwortlicher	baut technische Migrationsstrecke, Validierung und Fehlerhandling
Business Validator	prüft Stichproben, Referenzfälle und fachliche Plausibilität
Projektleitung	koordiniert Zeitplan, Risiken, Eskalationen und Cutover
Steering Committee	entscheidet bei Scope-, Risiko- und Go/No-Go-Konflikten

Die Unterscheidung ist wichtig, weil sie eine einfache Wahrheit sichtbar macht: Daten haben eine technische und eine fachliche Seite. Die technische Seite fragt: Können Daten extrahiert, transformiert, geladen und validiert werden? Die fachliche Seite fragt: Sind diese Daten richtig, vollständig, relevant und geschäftlich sinnvoll? Beides muss zusammenkommen. Wenn eine Rolle fehlt, steigt das Risiko. Ohne Data Owner fehlt die fachliche Entscheidung. Ohne technische Migrationsverantwortung fehlt die reproduzierbare Umsetzung. Ohne Business Validator kann eine Migration technisch sauber sein, aber im Alltag trotzdem nicht funktionieren. In kleineren Projekten können Rollen kombiniert werden. Dann übernimmt vielleicht ein Key User zugleich Data-Owner- und Validator-Aufgaben. Das ist in Ordnung, solange die Verantwortung explizit ist. Kritisch wird es, wenn Rollen nur implizit erwartet werden. Gerade wenn intern wenig Erfahrung mit ERP-Datenmigration vorhanden ist, kann externe Struktur helfen. Das gilt nicht nur für die technische Migration, sondern auch für Scope, Datenqualität, Verantwortlichkeiten und Entscheidungslogik. Der Beitrag So finden Sie den richtigen Auswahlberater für Ihr ERP-Projekt finden für Ihr ERP-Projekt zeigt ergänzend, worauf Unternehmen bei externer Unterstützung achten sollten.

Expertenimpuls: Datenmigration strukturiert vorbereiten

Datenmigration lässt sich nicht mit einer Präsentation lösen. Aber sie lässt sich besser vorbereiten, wenn Projektteam, Fachbereiche und Management ein gemeinsames Verständnis der kritischen Fragen entwickeln. Dazu gehören unter anderem:

• Welche Datenbereiche sind für den Go-Live wirklich kritisch?
• Wo ist die Datenqualität noch unklar?
• Welche Systeme sind betroffen?
• Welche Migrationsstrategie passt zur Risikolage?
• Wer muss fachlich entscheiden?
• Welche Tests sind vor dem Go-Live notwendig?
• Welche Daten sollten nicht ins neue ERP übernommen werden?

Genau hier kann ein strukturierter Expertenblick helfen. Nicht, um sofort ein Tool auszuwählen, sondern um die Ausgangslage einzuordnen: Welche Risiken sind bereits sichtbar? Wo braucht es Datenprofiling? Welche Verantwortlichkeiten fehlen? Und welche Punkte sollten vor Anbieterentscheidung, Projektstart oder Cutover geklärt werden?

Wie Find-Your-ERP bei der Vorbereitung helfen kann

Datenmigration beginnt nicht erst, wenn ein neues ERP-System bereits ausgewählt ist. Sie sollte schon in der Auswahl- und Vorbereitungsphase mitgedacht werden. Denn die spätere Migration hängt stark davon ab, welches Zielsystem gewählt wird, welches Datenmodell es nutzt, welche Pflichtfelder es verlangt, welche Schnittstellen benötigt werden und wie gut es zur bestehenden Prozess- und Datenlandschaft passt. Ein System kann funktional überzeugend wirken und trotzdem hohe Migrationsaufwände verursachen, wenn Datenmodell, Integrationslogik oder Einführungsansatz nicht zur Ausgangslage passen. Deshalb sollte man die ERP-Auswahl richtig aufsetzen, wenn später Migrationsrisiken reduziert werden sollen. Relevant ist nicht nur, welche Funktionen benötigt werden. Relevant ist auch, welche Datenbasis vorhanden ist, welche Systeme angebunden sind, welche Prozesse im Zielsystem abgebildet werden müssen und welche Risiken schon vor der Auswahl sichtbar werden. Wenn Sie eine ERP-Ablösung oder Einführung vorbereiten, kann eine frühe Einordnung der Datenlage sinnvoll sein: Welche Daten sind migrationsrelevant? Wo bestehen Qualitätsrisiken? Welche Systeme sind betroffen? Und welche Punkte sollten vor Anbieterentscheidung, Projektstart oder Go-Live geklärt werden? Ein passender nächster Schritt kann ein Expertengespräch sein, ERP-Projekt und Datenlage im Expertengespräch einordnen und Migrationsrisiken gemeinsam einzuordnen.

Fazit: Gute ERP-Datenmigration beginnt lange vor dem Go-Live

Datenmigration ist nicht der letzte technische Schritt vor dem Go-Live. Sie ist ein zentrales Arbeitspaket der ERP-Strategie. Ein neues ERP-System kann Prozesse verbessern, Transparenz schaffen und Steuerung erleichtern. Es kann aber keine fehlende Datenqualität, unklare Verantwortlichkeiten oder nicht entschiedene Altlasten kompensieren. Wenn Stammdaten unvollständig sind, offene Vorgänge nicht sauber abgegrenzt wurden oder verbundene Systeme nicht berücksichtigt sind, wird das neue ERP seine Wirkung nicht entfalten. Gute Datenmigration beginnt deshalb früh. Sie klärt, welche Daten wirklich benötigt werden, welche Qualität sie haben, wer sie fachlich verantwortet, wie sie transformiert werden, wie verbundene Systeme eingebunden sind und nach welchen Kriterien der Go-Live freigegeben wird. Der wichtigste Perspektivwechsel lautet: Migration bedeutet nicht, das alte System möglichst vollständig in das neue zu kopieren. Migration bedeutet, eine belastbare Datenbasis für die künftigen Prozesse zu schaffen. Wer diesen Punkt ernst nimmt, reduziert nicht nur technische Risiken. Er schafft auch bessere Voraussetzungen dafür, dass das neue ERP-System ab dem ersten produktiven Tag akzeptiert wird und verlässlich arbeitet.

FAQ: Häufige Fragen zur Datenmigration im ERP-Projekt