Datenmigration in Dynamics 365 — der umfassende Leitfaden für sichere, saubere und effiziente ERP-Migrationsprojekte – Teil 1

Die Datenmigration ist weit mehr als ein technischer Kopiervorgang: Sie bestimmt, ob Ihr neues ERP-System von Anfang an zuverlässige Informationen liefert oder ob Sie Tage nach dem Live-Gang mit der Datenbereinigung, Buchungen und Support-Tickets verbringen müssen.

Was ist Datenmigration — und wie unterscheidet sie sich von Integration oder Schnittstellenarbeit?

Datenmigration bezieht sich auf den Prozess, bestehende Daten von einem oder mehreren Quellsystemen in ein neues Zielsystem zu übertragen. Im Kontext von ERP bedeutet dies, dass Stammdaten (Kunden, Lieferanten, Artikel), offene Dokumente (Bestellungen, Eingangsrechnungen), Bestände, Eröffnungsbuchungen und oft auch einige historische Transaktionen übertragen werden. Im Gegensatz zu laufenden Integrationen (ETL/ELT-Prozesse oder EDI-Verbindungen), die Daten dauerhaft synchronisieren oder austauschen, ist die Migration in der Regel ein einmaliges oder zeitlich begrenztes Projekt mit klaren Schnittzeitfenstern, Tests und einem definierten Abschlussdatum. Migration ist daher ein Transformationsprojekt: Daten müssen extrahiert, bereinigt, transformiert, validiert und in das Zielsystem geladen werden.

Warum ist eine gut geplante Datenmigration besonders wichtig für Dynamics 365?

Dynamics 365 Finance & Supply Chain Management ist ein umfassendes, konfigurierbares System, das auf konsistenten Stammdaten und gültigen Referenzen basiert. Falsche Artikelstammdaten, ungültige Kontenpläne oder unvollständig übertragene offene Posten führen direkt zu Buchungsfehlern, fehlenden Bestellungen oder falschen Bestandswerten. Darüber hinaus betreiben viele Unternehmen Dynamics 365 als Cloud SaaS: direkter SQL-Zugriff auf die Produktionsdatenbank ist oft nicht verfügbar, was bedeutet, dass nur unterstützte Methoden (Datenentitäten, Datenmanagement-Framework, APIs, Dual Write/Dataverse) verwendet werden dürfen. Daher ist ein strukturierter Ansatz unerlässlich – von der Auswahl der zu migrierenden Daten bis hin zur Abbildung und Validierung nach dem Laden.

Welche Daten sollten migriert werden – und welche ist besser archiviert zu bleiben?

Nicht alle Daten müssen unbedingt im vollen Detail migriert werden. Eine sinnvolle Auswahl basiert auf der Nutzbarkeit im Tagesgeschäft und den regulatorischen Anforderungen. Typischerweise umfassen die Mindestdatensätze:

• Stammdaten: Kunden, Lieferanten, Artikel, Konten, Preismatrizen, Lagerorte.

• Aktive offene Transaktionen: offene Aufträge, offene Bestellungen, offene Lieferantenrechnungen, Zahlungszuweisungen.

• Eröffnungsbilanzen und Bilanz/Rechnungsstellung zum Zeitpunkt der Migration.

Historische Transaktionsdaten (z. B. alle Buchungszeilen aus den Vorjahren oder abgeschlossenen Verkaufsjahren) werden oft nicht vollständig in operationale Tabellen übertragen, sondern vielmehr in ein Reporting-Archiv oder eine Datenlagerumgebung übertragen. Viele Teams entscheiden sich für eine hybride Lösung: Nur die letzten 2–3 Jahre operativer Transaktionen werden migriert, während ältere Daten im Archiv verbleiben und über Reporting-Lösungen oder ein Nur-Lese-System verfügbar sind. Es ist entscheidend, dass die gewählte Strategie die Anforderungen an die Prüfungs-Compliance, die Reporting-Anforderungen und die operationale Notwendigkeit berücksichtigt.

Vorbereitung: Schritte, die vor dem ersten Datentransfer zu unternehmen sind

Erfolgreiche Migrationen beginnen nicht mit dem ersten Export, sondern mit einer systematischen Analyse:Zuerst ist ein Dateninventar notwendig: alle relevanten Datenquellen identifizieren, bestehende Datenschemata dokumentieren und Verantwortlichkeiten (Datenverantwortliche) zuweisen. Datenprofiling und Qualitätsbewertungen werden parallel durchgeführt: Wie viele Duplikate gibt es? Wie viele Pflichtfelder fehlen? Welche Felder weichen strukturell vom Ziel ab?

Auf der Grundlage dieser Analyse wird ein Migrationskonzept entwickelt, das den Umfang, die Migrationsregeln, Transformationen, Validierungsregeln und Abnahmekriterien beschreibt. Governance-Fragen werden geklärt: Wer entscheidet im Falle von widersprüchlichen Stammdaten? Welche Daten dürfen im Zielsystem vorhanden sein? Welche Testdaten und Maskierungen sind für sensible Informationen erforderlich?

Strategische Entscheidungen: Big Bang vs. phasenweise Migration

Bei der Migrationsstrategie gibt es in der Regel zwei Modelle zur Auswahl. Beim Big Bang werden alle relevanten Daten innerhalb eines eng definierten Ablaufs in das neue System geladen und die alten Systeme heruntergefahren. Vorteil: weniger Doppelbetrieb, klare Trennung. Nachteil: sehr hoher Druck beim Testen, großer Koordinationsbedarf und höhere Risiken zum Zeitpunkt des Go-Live.

Die phasenweise oder schrittweise Migration überträgt Daten schrittweise – zum Beispiel zuerst Stammdaten und offene Posten, dann historische Daten oder spezifische Module. Vorteil: geringere Risiken pro Release, Möglichkeit, Prozesse zu stabilisieren und das Team zu schulen. Nachteil: längerer Doppelbetrieb und komplexere Synchronisierungsanforderungen. Welche Strategie sinnvoll ist, hängt von den Geschäftsprozessen, den regulatorischen Anforderungen, dem Datenvolumen und der Risikobereitschaft ab.

Technische Werkzeuge und Konzepte für Dynamics-Migrationen

Microsoft bietet mehrere native Optionen für Dynamics 365, die in der Praxis oft mit externen ETL-Tools kombiniert werden:

Das Data Management Framework (DMF) ist das zentrale, integrierte Werkzeug in Dynamics 365 zum Importieren und Exportieren großer Datenmengen. Es verwendet sogenannte Datenentitäten (vordefinierte oder projektspezifische Entitäten), mit denen Daten in Datenpaketen (ZIP) verpackt und geladen werden können. Bei komplexen Transformationen oder wenn Daten aus vielen heterogenen Quellen stammen, werden oft zusätzliche Werkzeuge verwendet.

Mapping und Transformation – die eigentliche Arbeit

Mapping steht im Mittelpunkt jeder Migration: Felder aus dem Altsystem müssen einer Entität und einem Feld in Dynamics 365 zugeordnet werden. Häufige Herausforderungen sind unterschiedliche Feldformate (z.B. Datumsformate, Maßeinheiten), unterschiedliche Kodierungen (Artikelnummern mit führenden Nullen), fehlende Referenzen oder Abweichungen von der Geschäftslogik (z.B. unterschiedliche Buchungsregeln). Gute Praxis ist es, Mapping-Regeln in einem nachvollziehbaren Dokument zu definieren, Nachschlagetabellen für Referenzdaten zu pflegen und Transformationen modular zu gestalten, sodass Anpassungen schnell in Testläufen umgesetzt werden können.

Ein typischer Fehler besteht darin, Mapping und Transformationen 'ad hoc' im Ladejob zu codieren. Es ist besser, ein wiederverwendbares Mapping-Artefakt zu erstellen, das getestet, versioniert und transparent dokumentiert ist. Automatisierte Unit-Tests für Transformationen (z.B. Generierung und Vergleich von erwarteten Zieldaten aus Testdatensätzen) reduzieren erheblich Risiken.

Datenbereinigung: Bereinigen vor dem Laden

Die meisten Migrationsprojekte scheitern nicht aufgrund des Ladevorgangs selbst, sondern wegen schlechter Datenqualität. Datenbereinigung ist eine wesentliche Voraussetzung: Duplikate entfernen, Pflichtfelder ausfüllen, veraltete oder nicht verwendete Stammdaten archivieren, Formate (Adressen, Telefonnummern) standardisieren und mit Referenzlisten (z. B. gültige Produktgruppen, Steuercodes) abgleichen.

Datenprofilierungswerkzeuge bieten Einblicke in die Verteilung von Werten und häufige Anomalien. Die Bereinigung muss mit den relevanten Abteilungen koordiniert werden: Welche Duplikate können gelöscht, welche zusammengeführt werden und wie kann die Historie erhalten bleiben? Ein häufig gewählter Ansatz ist die Bildung eines speziellen Bereinigungsteams aus Fachleuten und Dateningenieuren, klare Regeln zu definieren und diese bereits in den Testmigrationen anzuwenden.

Wie der Go-Live ablaufen sollte und worauf Sie während und nach dem Go-Live unbedingt achten sollten, wird im Teil 2 unseres Blogs erklärt.