ERP-Datenmigration: vom Datenanalyse-Workshop zur produktiven Übernahme

Die Datenmigration ist statistisch der häufigste Grund für verzögerte oder gescheiterte ERP-Go-Live-Termine — über 60 % der Implementierungs-Probleme nach Trovarit-Studie 2024 haben ihre Wurzel in Datenmigration. Der Grund: Datenqualität wird oft erst entdeckt, wenn die Migration läuft, nicht während der Vorbereitung.

Dieser Beitrag beschreibt einen strukturierten Migrations-Ansatz, der die häufigsten Fallstricke vermeidet — von der Datenanalyse über die ETL-Strategie bis zum produktiven Cutover.

Datenkreise im ERP: Stammdaten, Bewegungen, Transaktionen

Vor der Migration muss klar sein, welche Datenkategorien überhaupt zu übernehmen sind. Stammdaten sind das Fundament: Kunden, Lieferanten, Artikel, Mitarbeiter, Kontenrahmen, Konditionen. Diese müssen vollständig und sauber im neuen System landen — sie sind die Grundlage für alle folgenden Vorgänge. Bewegungsdaten sind operative Vorgänge: offene Aufträge, Bestellungen, Lager-Bewegungen. Sie werden zum Stichtag synchronisiert — nicht historisch, sondern in der aktuellen Form. Transaktionsdaten / Buchhaltung: Eröffnungsbilanz, OPOS-Salden, USt-Voranmeldungen. Steuerlich kritisch — meist unter Steuerberater-Beteiligung. Historische Daten: alte Aufträge, alte Buchungen für Vergleichbarkeit. Frage: wirklich migrieren oder im alten System (read-only) parken? Letzteres oft günstiger.

Datenanalyse-Workshop: Datenqualität vor der Migration

Im Idealfall geht 4-12 Wochen vor dem geplanten Migrations-Termin ein Datenanalyse-Workshop voran. Aufgaben: Vollständigkeits-Check (welche Datensätze existieren überhaupt, gibt es Lücken in Pflichtfeldern), Plausibilitäts-Check (sind die Daten konsistent — z. B. Aufträge ohne Kunden-Zuordnung, Artikel ohne Konditionen), Duplikate-Erkennung (gleiche Kunden mit unterschiedlichen Schreibweisen, doppelte Artikel-Stämme), Mapping zur Ziel-Struktur (welches Feld im Alt-System wird zu welchem Feld im Neu-System). Output: Datenqualitäts-Report mit Issues und priorisierte Bereinigungs-Roadmap. Faustregel: wer in der Daten-Analyse 5 % Probleme findet, hat in der Migration 25 % Aufwand.

ETL-Strategie: Tools und Patterns

ETL (Extract-Transform-Load) ist die technische Migrations-Methodik. Architektur-Optionen: Native ERP-Migrations-Tools: jeder größere ERP-Anbieter hat eigene (SAP Migration Cockpit, Microsoft Dynamics 365 Data Migration Tool, Oracle Data Integrator). Vorteil: getestete Standards, Nachteil: weniger flexibel bei komplexen Transformationen. Generelle ETL-Plattformen: Talend, Apache NiFi, Pentaho, Microsoft SSIS. Mehr Flexibilität, aber höhere Lernkurve. Custom-Skripte: Python/SQL-basiert. Nur für sehr einfache Migrationen sinnvoll, Wartbarkeit oft problematisch. iPaaS-basierte Migration: Boomi, MuleSoft können auch Migrations-Aufgaben übernehmen, lohnt sich wenn die Plattform sowieso für laufende Integrationen vorgesehen ist.

Stichtags-Konzept und Cutover-Planung

Der Cutover-Plan ist die detaillierte Stunden-Choreografie der Migrations-Phase. Typischer Ablauf bei einem Wochenend-Cutover: Freitag Abend: Altsystem stillgelegt, finale Buchungen und offene Vorgänge gesichert. Samstag: Stammdaten-Migration ins Neusystem, technische Validierung. Sonntag: Bewegungsdaten-Migration, Eröffnungsbilanz, manuelle Spot-Checks. Sonntag Abend: Smoke-Tests durch Key-User, Go/No-Go-Entscheidung. Montag früh: produktiver Start. Wichtig: Roll-Back-Plan muss ausformuliert sein — bei welcher Eskalation wird zurück auf das Altsystem gewechselt, wie lange dauert das, welche Bedingungen müssen erfüllt sein? Ohne Roll-Back-Option ist der Cutover ein Vabanque-Spiel.

Validierung: Tests, Tests, Tests

Jede migrierte Datenkategorie muss validiert werden. Zwei Test-Schichten: Technische Validierung (automatisierbar): Datensatz-Anzahl Alt vs. Neu, Summen-Vergleiche (z. B. Summe aller Forderungen), Pflichtfeld-Vollständigkeit. Fachliche Validierung (manuell durch Key-User): Stichproben aus den wichtigsten Datenkategorien (z. B. 30 zufällige Kunden, 30 Artikel, 30 offene Aufträge), inhaltliche Prüfung gegen das Altsystem. Test-Migrationen vor dem echten Cutover sind Pflicht. Best Practice: 3 Test-Migrationen — Initial-Test (Mocking, alle Komponenten technisch getestet), Pre-Final-Test (mit aktuellen Daten, ~6 Wochen vor Go-Live), Final-Test (mit aktuellen Daten, 1-2 Wochen vor Go-Live).