ERP-Datenmigration: Best Practices und häufige Fallstricke

Bei der Datenmigration entscheiden ERP-Implementierungen auf der grundlegendsten Ebene über Erfolg oder Misserfolg. Sie können eine perfekte Systemarchitektur entwerfen, die Software fehlerfrei konfigurieren und Benutzer umfassend schulen – und dann scheitert die Implementierung, weil die Daten, die sie speisen, falsch sind.

Der Begriff „Datenmigration“ klingt technisch und operativ. In der Praxis handelt es sich um eine organisationsweite Übung zur Bewältigung der über Jahre hinweg angehäuften Datenqualitätsschulden. Doppelte Kundendatensätze, inkonsistente Produktcodes, nicht abgeglichene Bestandszahlen, fehlende Lieferanteninformationen und alte Datenstrukturen, die nicht sauber auf moderne ERP-Datenmodelle abgebildet werden können – diese Probleme verschwinden nicht, weil ein neues System installiert wurde. Sie migrieren und verursachen im neuen System Probleme, deren Behebung manchmal teurer ist als im alten.

Dieser Leitfaden deckt den gesamten Datenmigrationslebenszyklus mit spezifischen, umsetzbaren Anleitungen für jede Phase und ehrlichen Beschreibungen der Fallstricke ab, auf die die meisten ERP-Migrationen stoßen.

Wichtige Erkenntnisse

Die Datenmigration ist in der Regel die am meisten unterschätzte Phase der ERP-Implementierung (Budget 3–5x anfängliche Schätzungen)

Beginnen Sie sechs bis zwölf Wochen vor Beginn der Implementierung mit der Datenqualitätsbewertung

Migrieren Sie niemals fehlerhafte Daten – bereinigen Sie sie zuerst, dann migrieren Sie saubere Daten

Der Ansatz „Einfach alles migrieren und später bereinigen“ schlägt zuverlässig fehl

Legen Sie die Dateneigentümerschaft vor der Migration fest: Wer ist für die Qualität jeder Dateneinheit verantwortlich? – Erstellen Sie Validierungsregeln vor der Migration, nicht während

Planen Sie zwei bis drei Migrationstestläufe vor der Cutover-Migration ein

Historische Daten und Eröffnungssalden sind separate Probleme mit unterschiedlichen Lösungen

Die vier Datentypen bei einer ERP-Migration

Nicht alle Daten bei einer ERP-Migration sind gleich. Das Verständnis der vier Typen und ihrer unterschiedlichen Migrationsherausforderungen ist der erste Schritt zur Planung einer erfolgreichen Migration.

Typ 1: Stammdaten

Stammdaten sind die Grundlage jeder Transaktion: Kundendatensätze, Lieferantendatensätze, Produkte (Artikel), Kontenpläne, Mitarbeiter und Lager-/Standorthierarchien. Die Qualität der Stammdaten bestimmt direkt die Qualität der Transaktionsdaten – wenn ein Kundendatensatz dupliziert wird, verschärft jede mit diesem Kunden verbundene Transaktion das Duplizierungsproblem.

Die Stammdatenmigration ist in der Regel die arbeitsintensivste Phase, da sie Geschäftsentscheidungen zu jedem aufgetretenen Datenqualitätsproblem erfordert. Sollten doppelte Kundendatensätze zusammengeführt werden? Wenn ja, welches ist die maßgebliche Aufzeichnung? Wie sollten Produkte mit inkonsistenten Maßeinheiten standardisiert werden?

Typ 2: Eröffnungssalden

Die Eröffnungssalden stellen die Finanzlage des Unternehmens zum Zeitpunkt der Inbetriebnahme dar: Debitorenbuchhaltung (wer schuldet Ihnen Geld), Verbindlichkeiten (wem Sie Geld schulden), Lagerbestände (welche Lagerbestände Sie zu welchem Preis halten) und die Salden der Hauptbuchkonten. Die Anfangssalden müssen auf den Cent genau sein – eine Abweichung von 0,01 $ bei den Forderungen führt monatelang zu Abstimmungsproblemen.

Die Anfangssalden werden mit dem Abschlussstatus des Altsystems abgeglichen und müssen genau abgeglichen werden, bevor die Produktivsetzung erfolgen kann. Diese Validierung deckt häufig Diskrepanzen zwischen dem Altsystem und dem tatsächlichen Geschäftsstatus auf (Rechnungen, die erfasst, aber nie gesendet wurden, Lagerbestände, die verbraucht, aber nicht erfasst wurden, erhaltene, aber nicht angewendete Zahlungen).

Typ 3: Transaktionsverlauf

Der Transaktionsverlauf ist die Aufzeichnung dessen, was passiert ist: Bestellungen, Verkaufsrechnungen, Lagerbewegungen, Personalunterlagen usw. Im Gegensatz zu Eröffnungssalden muss der Transaktionsverlauf nicht vollkommen genau sein, um Vorgänge zu ermöglichen – er muss für Berichts-, Prüf- und Referenzzwecke genau genug sein.

Für die meisten Implementierungen reicht die Transaktionshistorie der letzten zwei bis drei Jahre aus. Ältere Historien können in der Regel als Referenz im Altsystem archiviert und nicht in das neue ERP migriert werden.

Typ 4: Konfigurationsdaten

Bei den Konfigurationsdaten handelt es sich nicht um Geschäftsdaten, sondern um die Einstellungen, die dafür sorgen, dass sich das System korrekt verhält: Zahlungsbedingungen, Steuersätze, Preisregeln, Workflow-Konfigurationen, Benutzerrollen und so weiter. Obwohl dies technisch gesehen Teil der „Migration“ ist, wird es genauer als Konfigurationsreplikation beschrieben – die Wiederherstellung der Geschäftsregeln des Altsystems im Konfigurationsmodell des neuen ERP.

Phase 1: Datenermittlung und -bewertung

Die Datenermittlungsphase sollte sechs bis zwölf Wochen vor dem Start der Implementierung beginnen – und nicht, nachdem die Implementierung bereits im Gange ist. Die häufigste Ursache für eine Überschreitung des ERP-Zeitrahmens ist die Entdeckung schwerwiegender Probleme mit der Datenqualität bereits während der Implementierung und nicht schon davor.

Der Datenbestand:

Katalogisieren Sie alle Datenentitäten, die in den Altsystemen vorhanden sind:

Welche Entitäten existieren (Kunden, Lieferanten, Produkte, Mitarbeiter usw.)
Wo jede Entität lebt (welches System oder welche Systeme) – Wie viele Datensätze für jede Entität vorhanden sind
Welches Format haben die Daten (relationale Datenbank, Flatfiles, Tabellenkalkulationen)?
Wer ist der Geschäftsinhaber, der für die Qualität jedes Unternehmens verantwortlich ist?

Die Datenqualitätsbewertung:

Führen Sie für jede größere Einheit eine quantitative Qualitätsbewertung durch, die Folgendes umfasst:

Vollständigkeit (bei welchem Prozentsatz der Datensätze sind alle erforderlichen Felder ausgefüllt?)
Eindeutigkeit (wie viel Prozent der Datensätze sind Duplikate oder Beinahe-Duplikate?)
Konsistenz (werden dieselben Werte in allen Datensätzen und Systemen konsistent dargestellt?)
Genauigkeit (stichprobenartige Überprüfung einer Stichprobe von Aufzeichnungen anhand der Grundwahrheit – Inventur, tatsächliche Lieferantenrechnungen, tatsächliche Kundenkorrespondenz)

Typische Qualitätsergebnisse bei ERP-Migrationen im Mittelstand:

8–20 % der Kundendatensätze sind Duplikate oder Beinahe-Duplikate
15–35 % der Produktdatensätze weisen fehlende oder inkonsistente Maßeinheitsdaten auf
10–25 % der Lagerbestände weisen Salden auf, die nicht mit der letzten physischen Zählung übereinstimmen
Alte Sachkonten, die seit Jahren nicht mehr verwendet wurden und stillgelegt werden sollten – Mitarbeiterdatensätze mit inkonsistenten Namenskonventionen, fehlenden Feldern oder veralteten Rolleninformationen

Die Migrationsrisikobewertung:

Basierend auf der Datenqualitätsbewertung klassifizieren Sie jede Dateneinheit nach dem Migrationsrisiko:

Geringes Risiko: saubere Daten, klare Zuordnung zur neuen ERP-Struktur, Standardformat
Mittleres Risiko: Einige Qualitätsmängel, Reinigung erforderlich, aber beherrschbar
Hohes Risiko: erhebliche Qualitätsprobleme, unklare Struktur oder komplexe Zuordnungsanforderungen

Unternehmen mit hohem Risiko benötigen längere Fristen, eine gezielte Einbindung der Geschäftsinhaber und möglicherweise spezielle Datenbereinigungstools oder -skripte.

Phase 2: Datenbereinigung

In der Datenbereinigung liegt die eigentliche Arbeit – und der wahre Wert – der Datenmigration. Ziel ist es, jede Dateneinheit auf ein Qualitätsniveau zu bringen, das für die Migration in das neue ERP geeignet ist.

Migrieren Sie niemals fehlerhafte Daten. Die Versuchung, Daten jetzt zu migrieren und später zu bereinigen, ist groß, insbesondere wenn die Bereinigung länger als geplant dauert. Widerstehen Sie ihm. Schlechte Daten in einem neuen ERP sind schlimmer als schlechte Daten in einem Altsystem, weil:

Die Validierungsregeln des neuen ERP kennzeichnen Fehler, die das Altsystem ignoriert hat, was zu unmittelbaren Betriebsproblemen führt
Benutzer, die im neuen ERP auf Datenqualitätsprobleme stoßen, geben dem neuen System die Schuld und nicht den zugrunde liegenden Datenqualitätsproblemen – Das Bereinigen von Daten nach der Migration erfordert ein Verständnis des neuen ERP-Datenmodells, was schwieriger ist als das Bereinigen von Daten in der bekannten Altstruktur

Datenbereinigungsprozess:

Wenden Sie für jede Entität mit hohem und mittlerem Risiko einen strukturierten Reinigungsprozess an:

Extrahieren Sie die Daten aus dem Altsystem in eine Staging-Umgebung
Führen Sie automatisierte Validierungsregeln aus, um alle Qualitätsprobleme zu identifizieren
Priorisieren Sie Probleme nach Umfang und Auswirkung (100 doppelte Kundendatensätze > 5 fehlende Postleitzahlen der Lieferanten)
Beheben Sie Probleme mit den Eingaben des Geschäftsinhabers (welcher ist der maßgebliche Datensatz, wenn zwei Kundendatensätze in Konflikt geraten?)
Dokumentieren Sie Entscheidungen und Beschlüsse für den Prüfpfad
Führen Sie die Validierungsregeln erneut aus, um zu bestätigen, dass alle Probleme behoben sind
Holen Sie vor der Migration die Genehmigung des Geschäftsinhabers für die bereinigten Daten ein

Tools zur Datenbereinigung:

ECOSIRE verwendet benutzerdefinierte Python-Skripte für die automatisierte Validierung und Transformation in Kombination mit Excel oder Google Sheets für die Überprüfung und Genehmigung einzelner Datensatzentscheidungen durch Geschäftsinhaber. Bei sehr großen Datensätzen bieten dedizierte ETL-Tools (Pentaho, Talend oder Cloud-native Äquivalente) eine bessere Leistung und Audit-Protokollierung.

Phase 3: Datenzuordnung und -transformation

Die Datenzuordnung definiert, wie Daten aus der Altsystemstruktur der Datenstruktur des neuen ERP zugeordnet werden. Dies ist eine technische Übung mit erheblichen geschäftlichen Input-Anforderungen.

Herausforderungen bei der Strukturkartierung:

Altsysteme verfügen oft über Datenstrukturen, die sich nicht sauber auf moderne ERP-Strukturen abbilden lassen. Häufige Herausforderungen:

Umstrukturierung des Kontenplans: Der alte Kontenplan kann Hunderte von Konten umfassen, die im neuen ERP in einer übersichtlicheren Struktur konsolidiert werden müssen. Jede Konsolidierungsentscheidung erfordert den Input des Finanzteams.
Änderungen der Produkthierarchie: Ältere Produktkataloge verfügen häufig über Ad-hoc-Hierarchien, die in das Kategorie-/Unterkategoriemodell des ERP umstrukturiert werden müssen. Jedes Produkt muss seiner neuen Kategorie zugeordnet werden.
Neukonfiguration mehrerer Währungen: Wenn das Unternehmen seit der Implementierung des Altsystems so gewachsen ist, dass es in mehreren Währungen operiert, muss die Währungskonfiguration im neuen ERP den aktuellen Stand widerspiegeln, nicht den historischen.

Transformationsregeln:

Über die strukturelle Zuordnung hinaus müssen Daten häufig transformiert werden, bevor sie den Formatanforderungen des neuen Systems entsprechen. Transformationsregeln sollten vor der Migration dokumentiert und vom Geschäftsinhaber überprüft werden. Häufige Transformationen:

Namensstandardisierung (alle Kunden im Format „Vorname“, alle Lieferanten mit eingetragenem Firmennamen)
Normalisierung des Telefonnummernformats (alle Nummern im internationalen E.164-Format)
Adressvalidierung und -standardisierung (Postleitzahlenvalidierung, Ländercode-Standardisierung)
Maßeinheitenumrechnung (historische Aufzeichnungen in alten Einheiten werden in ERP-Standardeinheiten umgewandelt)
Statuscode-Zuordnung (Altsystem-Statuscodes werden ERP-Statuswerten zugeordnet)

Das Datenzuordnungsdokument:

Erstellen Sie ein formelles Datenzuordnungsdokument, das für jedes Feld im Altsystem das entsprechende Feld im neuen ERP, alle angewendeten Transformationen und die Geschäftsregel, die die Zuordnung regelt, zeigt. Dieses Dokument ist wichtig für: – Validierung des Migrationsskripts anhand des beabsichtigten Verhaltens

Behebung von während des Tests festgestellten Unstimmigkeiten
Unterstützung bei Audit-Anfragen nach dem Go-Live

Phase 4: Migrationsentwicklung und -tests

Nachdem die Bereinigung abgeschlossen und das Mapping dokumentiert ist, können die Migrationsskripte entwickelt und getestet werden.

Entwicklung von Migrationsskripten:

Migrationsskripte extrahieren bereinigte Daten aus der Staging-Umgebung, wenden Transformationen entsprechend dem Mapping-Dokument an und laden die transformierten Daten in das neue ERP. ECOSIRE entwickelt Migrationsskripte in Python und nutzt zum Laden die Odoo XML-RPC API. Zu den Skripten gehören:

Validierung vor der Migration (bestätigen Sie, dass die Daten in der Staging-Umgebung mit dem genehmigten bereinigten Datensatz übereinstimmen)
Stapelverarbeitung mit Fehlerprotokollierung (zeichnen Sie alle Datensätze auf, die nicht zur manuellen Überprüfung geladen werden können)
Validierung nach der Migration (bestätigen Sie, dass die geladenen Daten mit den erwarteten Zählungen und Werten übereinstimmen)
Rollback-Fähigkeit (wenn ein Migrationslauf zu unerwarteten Ergebnissen führt, die Möglichkeit, das ERP auf den Zustand vor der Migration zurückzusetzen)

Testmigrationsläufe:

Planen Sie vor der Cutover-Migration zwei bis drei Testmigrationsläufe ein:

Testlauf 1 (Woche X): Validieren Sie die Grundfunktionalität des Migrationsskripts und identifizieren Sie etwaige Transformationsfehler
Testlauf 2 (Woche X+2): Validierung anhand eines vollständigeren und saubereren Datensatzes; den ersten vollständigen Validierungsbericht erstellen
**Testlauf 3 / Generalprobe (Woche

Bei jedem Testlauf sollte ein Validierungsbericht erstellt werden, der die migrierten Daten mit den erwarteten Zählungen, Werten und Einschränkungen der referenziellen Integrität vergleicht. Unstimmigkeiten müssen vor dem nächsten Testlauf behoben werden.

Phase 5: Eröffnungsbilanzabstimmung

Der Abgleich des Eröffnungssaldos ist von der Migration der Stammdaten und des Transaktionsverlaufs getrennt, da er eine finanzielle Genauigkeit zu einem bestimmten Zeitpunkt und nicht nur die Vollständigkeit der Daten erfordert.

Der Versöhnungsprozess:

Extrahieren Sie am vereinbarten Umstellungstermin die Schlusssalden aus dem Altsystem für jede Finanzeinheit: Fälligkeit der Forderungen, Fälligkeit der Verbindlichkeiten, Lagerbestände nach Standort, Sachkontensalden. Diese werden zu den Eröffnungssalden im neuen ERP.

Gleichen Sie die extrahierten Salden ab mit:

Die aktuellsten Kontoauszüge (für Geldkonten)
Der jüngste Bericht über die Alterung der Forderungen wurde von AR-Mitarbeitern bestätigt
Der jüngste Bericht über die Fälligkeit der Kreditorenbuchhaltung wurde von den Mitarbeitern der Kreditorenbuchhaltung bestätigt – Die letzte Inventurzählung, angepasst an Bewegungen seit dem Zähldatum

Jegliche Diskrepanz zwischen dem extrahierten Saldo und der Grundwahrheit muss vor dem Go-Live behoben werden. Wenn Sie die Diskrepanz in das neue System übertragen, wird es monatelang zu Abstimmungsproblemen kommen.

Das Problem der „immer offenen“ Rechnung:

In den meisten alten Buchhaltungssystemen gibt es eine Reihe von Rechnungen, die technisch offen (nicht vollständig bezahlt), aber funktional tot sind – umstritten, uneinbringlich oder administrativ aufgegeben. Diese „immer offenen“ Rechnungen sollten nicht als offene AR migriert werden. Sie sollten vor der Migration abgeschrieben oder als uneinbringlich markiert werden. Das Finanzteam muss zu jedem Einzelnen explizite Entscheidungen treffen.

Phase 6: Cutover-Planung und -Ausführung

Der Cutover ist der Moment, in dem das Altsystem stoppt und das neue ERP startet. Eine präzise Planung der Cutover-Reihenfolge verhindert Chaos am Go-Live-Tag.

Der Umstellungsplan:

Dokumentieren Sie jeden Schritt des Umstellungsprozesses mit:

Wer führt den Schritt aus?
Geschätzte Dauer des Schritts
Abhängigkeiten (was muss abgeschlossen sein, bevor dieser Schritt beginnt)
Validierungsprüfung (wie Sie bestätigen, dass der Schritt vollständig und korrekt ist)
Rollback-Aktion (was tun, wenn dieser Schritt fehlschlägt)

Eine typische Umstellung dauert bei einem Unternehmen mit 100 Mitarbeitern 8–16 Stunden. Die Umstellung erfolgt in der Regel über ein Wochenende, um Geschäftsunterbrechungen so gering wie möglich zu halten.

Umstellungssequenz:

Einfrieren des Altsystems: Es sind keine neuen Transaktionen zulässig
Endgültiger Datenextrakt aus dem Altsystem
Abschließende Datenvalidierung und -bereinigung (alle seit dem letzten Testlauf entdeckten Probleme)
Ausführung des Migrationsskripts für Stammdaten
Migration und Validierung der Eröffnungsbilanz
Migration des Transaktionsverlaufs (bei Migration des aktuellen Verlaufs)
Vollständige Überprüfung des Validierungsberichts und Freigabe durch die Finanzabteilung
Validierung der Systemkonfiguration (alle Einstellungen korrekt)
Neues ERP wurde in Betrieb genommen

Häufige Fallstricke und wie man sie vermeidet

Falle 1: Alles migrieren

Der Impuls, alle historischen Daten zu migrieren, ist verständlich, aber oft kontraproduktiv. Die Migration, Validierung und das Laden des zehnjährigen Transaktionsverlaufs eines Altsystems dauert Wochen – und das meiste davon wird nie abgefragt. Definieren Sie einen Migrationshorizont (normalerweise zwei bis drei Jahre) und archivieren Sie ältere Historien im Altsystem, anstatt sie zu migrieren.

Falle 2: Angenommen, die Altsystemdaten seien die Quelle der Wahrheit

Altsystemdaten sind häufig falsch. Wenn Sie es als maßgeblich betrachten, migrieren Sie die Fehler in das neue System. Physische Zählungen, Kontoauszüge und Lieferantenabrechnungen sind bessere Informationsquellen für Eröffnungssalden als alte Systemberichte.

Falle 3: Keine Testumgebung

Die direkte Migration zur Produktion ohne Tests in einer Sandbox-Umgebung ist mit hohem Risiko verbunden. Pflegen Sie für die Migrationstestphase stets eine Testumgebung, die die Produktion widerspiegelt.

Falle 4: Unzureichende Einbindung der Geschäftsinhaber

Entscheidungen zur Datenbereinigung und -zuordnung erfordern geschäftliches Urteilsvermögen, über das technische Teams nicht verfügen. Eine unzureichende Einbeziehung der Geschäftsinhaber führt dazu, dass technische Teams falsche Geschäftsentscheidungen treffen, was zu Problemen mit der Datenqualität führt, die sich nach der Inbetriebnahme als betriebliche Probleme bemerkbar machen.

Falle 5: Kein Rollback-Plan

Bei jedem Go-Live sollte es einen expliziten Rollback-Plan geben: Wenn das neue System in den ersten 24 bis 48 Stunden nicht ordnungsgemäß funktioniert, wie erfolgt dann die Rückkehr zum Altsystem? Wenn dieser Plan fertig ist, verringert sich der Druck, in einer Krise voreilige Entscheidungen zu treffen.

Häufig gestellte Fragen

Wie lange sollten wir für die Datenmigration in einer ERP-Implementierung einplanen?

Planen Sie für ein mittelständisches Unternehmen (100–300 Mitarbeiter, 2–5 Datenquellensysteme) sechs bis zehn Wochen für die Datenmigration als dedizierte Phase ein, beginnend, nachdem die Konfiguration vollständig genug ist, um die Zieldatenstruktur festzulegen. Planen Sie außerdem vier bis sechs Wochen vor dem Start der Implementierung für die Bewertung der Datenqualität und die erste Bereinigung ein. Die Gesamtinvestition in die Datenmigration beträgt in der Regel zehn bis sechzehn Wochen von der ersten Bewertung bis zur Umstellung.

Sollten wir die Daten vor oder während der Implementierung bereinigen?

Vorher, immer. Die Datenbereinigung, die parallel zur Implementierung erfolgt, nutzt dieselben Geschäftsinhaberressourcen, die das Implementierungsteam für die Konfigurationsvalidierung und -tests benötigt. Außerdem verzögert sich dadurch der Zeitplan für die Migration, da die Bereinigung von Geschäftsentscheidungen abhängt, deren Zusammenführung Zeit in Anspruch nimmt. Der effektivste Ansatz ist es, mit der Datenbereinigung sechs bis zwölf Wochen vor dem Start der Implementierung zu beginnen.

Kann ECOSIRE Daten aus jedem älteren ERP-System migrieren?

ECOSIRE hat Migrationstools für SAP Business One, QuickBooks (Desktop und Online), Sage 50 und Sage 100, Microsoft Dynamics (GP, NAV, BC) und mehrere branchenspezifische Plattformen entwickelt. Für andere Systeme basiert der Migrationsansatz auf dem verfügbaren Exportformat – SQL-Datenbank, XML, CSV-Exporte oder API-Zugriff. Es wurde kein Altsystem gefunden, das nicht migriert werden konnte, allerdings variiert der Aufwand je nach Quellsystem erheblich.

Wie hoch sind die typischen Kosten für die Datenmigration in einer ERP-Implementierung?

Bei ECOSIRE-Implementierungen macht die Datenmigration typischerweise 15–25 % der gesamten Implementierungskosten aus. Bei einer Implementierung im Wert von 150.000 US-Dollar betragen die Kosten für die Datenmigration 22.000 bis 37.000 US-Dollar. Der Bereich hängt in erster Linie von der Datenqualität (geringere Qualität = höhere Reinigungskosten) und dem Datenvolumen (mehr Datensätze = mehr Zeit für die Skriptentwicklung und -validierung) ab. Datenqualitätsprobleme, die nach Beginn der Migration entdeckt werden, können diese Kosten erheblich erhöhen, weshalb die Investition in die Bewertung vor der Implementierung so wertvoll ist.

Nächste Schritte

Wenn Sie eine ERP-Implementierung planen und Hilfe bei der Bewertung Ihrer Datenqualität benötigen, bevor Sie Zeit- und Budgetverpflichtungen eingehen, bietet ECOSIRE eine Datenbereitschaftsbewertung an, die Ihre wichtigsten Dateneinheiten bewertet, Qualitätsprobleme identifiziert und realistische Schätzungen für die Migrationsphase liefert.

Erfahren Sie mehr über die Odoo-Migrationspraxis von ECOSIRE unter /services/odoo/migration.

ERP Data Migration: Best Practices and Common Pitfalls