Datenmigration in Business Central: Strategie & Umsetzung für einen sicheren Go-Live

Teil 4 von 8 in der Business-Central-Implementierungsserie

Veröffentlicht: Dezember 2025 | Lesezeit: 14 Minuten

Einleitung

Die Datenmigration ist oft die am meisten unterschätzte – und gleichzeitig eine der kritischsten – Phasen einer Business-Central-Implementierung. Sie ist die Brücke zwischen Altsystem(en) und Ihrer neuen ERP-Plattform: Der Prozess, der Ihre Unternehmenshistorie, Beziehungen und operativen Daten in die konfigurierte Business-Central-Umgebung bringt.

Es ist verführerisch, Datenmigration als „Lift & Shift“ zu betrachten. In der Praxis gelingen Migrationen jedoch nur mit sauberer Planung, konsequenter Datenbereinigung, systematischer Validierung und disziplinierter Umsetzung. Eine schlechte Migration kann ein ansonsten gutes Projekt massiv beschädigen; eine gute Migration schafft die Grundlage für einen souveränen Go-Live und nachhaltigen Erfolg.

Dieser Leitfaden liefert ein strategisches Framework für Planung und Umsetzung der Business-Central-Datenmigration – von der ersten Bestandsaufnahme bis zur finalen Cutover-Validierung.

Datenmigration planen: Strategie und Vorgehen

Eine erfolgreiche Migration startet mit Planung, die Vollständigkeit und Pragmatismus ausbalanciert.

Migrationsumfang definieren

Nicht jedes Datum „verdient“ Migration. Sie müssen strategisch entscheiden, was migriert wird und was archiviert bleibt.

Stammdaten vs. Bewegungsdaten:

Stammdaten (immer migrieren):

• Kunden und Kundenkontakte

• Lieferanten und Lieferantenkontakte

• Artikel und Bestandsstammdaten

• Kontenplan

• Anlagen

• Mitarbeitende (falls Business Central dafür genutzt wird)

• Preislisten und Rabatte

• Stücklisten (bei Fertigung)

Bewegungsdaten (selektiv migrieren):

• Offene Posten/Offene Vorgänge (müssen migriert werden):

  • Offene Debitorenrechnungen und Gutschriften

  • Offene Kreditorenrechnungen und Gutschriften

  • Offene Bestellungen

  • Offene Verkaufsaufträge

  • Offene Banktransaktionen

• Historische Bewegungen (kritisch prüfen):

  • Gebuchte Rechnungen und Belege

  • Zahlungshistorie

  • Hauptbuchhistorie

  • Lagerbewegungen

  • Geschlossene Aufträge/Angebote

Entscheidungen zur Historie:

Vollständige Historienmigration:

• Vorteile: Vollständige Historie im System, umfassendes Reporting, durchgängiger Audit Trail

• Nachteile: Längere Migration, größere Datenbank, mehr Validierung, höhere Kosten

• Sinnvoll für: Stark regulierte Branchen, Litigation-Risiken, intensive historische Analysen

Selektive Historienmigration:

• Vorteile: Schnellere Migration, „sauberer Start“, geringere Komplexität

• Nachteile: Begrenztes historisches Reporting, potenzielle Lücken im Audit Trail

• Sinnvoll für: Die meisten Implementierungen (v. a. wenn das Altsystem lesbar bleibt)

Nur Eröffnungsbestände:

• Vorteile: Schnellster Ansatz, wenig Datenvolumen, klarer Start

• Nachteile: Keine Transaktionsdetails, weniger historische Insights

• Sinnvoll für: Kleinere Unternehmen, wenn Altsystem für Historie verfügbar bleibt

Empfohlenes Vorgehen:

• Stammdaten: vollständig und aktuell

• Offene Vorgänge: alle offenen Posten/Dokumente

• Gebuchte Belege: letzte 12–24 Monate

• GL-Balances: Eröffnungsbestände zum Go-Live (optional mit Detailhistorie)

• Archiv: Altsystem read-only für historische Nachfragen

Timing und Cutover-Strategie

Gutes Timing minimiert Störungen und erleichtert Abstimmung/Abschluss.

Cutover-Timing – Optionen:

Cutover zum Monats-/Quartalsende:

• Vorteile: Sauberer Periodenwechsel, einfachere Abstimmung, passt zu Reporting-Zyklen

• Herausforderungen: Oft Peak-Zeit für Finance, Druck, in zwei Systemen „zu schließen“

Cutover innerhalb der Periode:

• Vorteile: Weniger Zeitdruck, bessere Verfügbarkeit, mehr Puffer für Issues

• Herausforderungen: Teilperioden in zwei Systemen, komplexere Abstimmung

Cutover zum Geschäftsjahresende:

• Vorteile: „Neustart“ fürs neue Jahr, Reporting/Steuerjahr sauber

• Herausforderungen: Lange Vorbereitung, Feiertage, eingeschränkte Supportverfügbarkeit

Empfehlung:

• Start eines Geschäftsjahres oder Quartals (wenn möglich)

• Alternativ: Monatsbeginn

• Peak-Phasen vermeiden (Saisonspitzen, Jahresabschluss)

• Nach Cutover ausreichend Stabilisierung vor Periodenabschluss einplanen

Parallelbetrieb (Parallel Run):

Temporär beide Systeme parallel betreiben.

Vorteile:

• Vertrauen durch Vergleich

• Sicherheitsnetz für kritische Prozesse

• Reduziert Umstellungsstress

• Validiert Konfiguration mit Live-Daten

Herausforderungen:

• Doppelte Datenerfassung

• Abstimmungsaufwand

• Längere Projektlaufzeit

• Gefahr von Verwirrung

Wann Parallel Run sinnvoll ist:

• Hohe Risiken/Komplexität

• Unsicherheit über Datenqualität

• Hohe User-Unsicherheit

• Regulatorische/vertragliche Anforderungen

Wann man ihn vermeiden sollte:

• Einfache Implementierungen

• Hohe Sicherheit durch Tests

• Umfangreiche Sandbox-Probenläufe

• Business kann Doppelbuchung nicht stemmen

Datenquellen und Altsysteme identifizieren

Ein vollständiges Inventar verhindert blinde Flecken.

Assessment der Quellsysteme:

Primäre Quellen:

• Legacy-ERP oder Buchhaltungssystem

• CRM

• Lagerverwaltung

• POS-Systeme

• Zeiterfassung

• Projektmanagement-Tools

• MES/Fertigungssteuerung

Ergänzende Quellen:

• Excel-Listen und Access/DBs

• E-Mail-Archive

• Papierakten (manuelle Erfassung)

• Drittanbieter-Daten

• Backup-Dateien

Pro Quellsystem dokumentieren:

• Systemname und Version

• Data Owner/Administrator

• Exportformate

• Extraktionsmöglichkeiten

• Datenqualitätslevel

• Letztes Update

• Zugriff/Verfügbarkeit

• Retention nach Go-Live

Typische Herausforderungen:

• Alte Systeme mit schwachen Exportmöglichkeiten

• Undokumentierte Custom-Systeme

• Mehrere Excel-„Systeme of Record“

• Wissen nur „im Kopf“ (Tribal Knowledge)

• Inkonsistenzen zwischen Quellen

• Fehlende Daten, die rekonstruiert werden müssen

Mitigation:

• IT früh einbinden (Extraktion)

• Business-Experten identifizieren (Datenbeziehungen)

• Zeit für Data Discovery einplanen

• Budget für „Data Archaeology“ bei Bedarf

• Bei komplexen Legacy-Systemen ggf. externe Extraktionsservices

Datenbereinigung und Validierung

Saubere Daten sind die Basis für Business-Central-Erfolg.

Datenqualitätsanalyse

Starten Sie mit einer systematischen Bewertung:

Dimensionen der Datenqualität:

Vollständigkeit:

• Pflichtfelder gefüllt

• Keine kritischen Informationslücken

• Related Records vorhanden

• Vollständige Adressen

Korrektheit:

• Daten entsprechen der Realität

• Keine offensichtlichen Fehler (z. B. negative Mengen ohne Sinn)

• Berechnungen korrekt

• Gültige Datumswerte

Konsistenz:

• Identische Entität gleich beschrieben

• Formate standardisiert

• Codes folgen Konventionen

• Related Data passt zusammen

Eindeutigkeit:

• Keine Dubletten

• IDs wirklich eindeutig

• Stammdaten nicht mehrfach angelegt

Validität:

• Werte entsprechen Business-Central-Constraints

• Wertebereiche plausibel

• Beziehungen sind gültig (z. B. Artikel hat Kategorie)

• Codes matchen Lookups

Aktualität:

• Daten sind aktuell

• Obsoletes identifiziert

• Status entspricht Realität

Data Profiling (Beispielstruktur):

1. Volumenanalyse:

   • Anzahl Datensätze je Entität

   • aktiv vs. inaktiv

   • historische Zeiträume

   • Wachstum

2. Feldbefüllung:

   • Anteil gefüllter Felder je Spalte

   • Muster fehlender Daten

   • Pflichtfeld-Compliance

3. Verteilung/Outlier:

   • Häufigkeiten

   • Ausreißer

   • Muster

   • Anomalien

4. Beziehungen:

   • Orphans (Child ohne Parent)

   • fehlende Beziehungen

   • Referential-Integrity-Verstöße

Strategien zur Datenbereinigung

Ziel: Problematische Quelldaten in hochwertige Business-Central-Daten transformieren.

Typische Bereinigungsaktivitäten:

Deduplizierung:

• Dubletten bei Kunden/Lieferanten/Artikeln finden

• Kriterien für Master Record definieren

• Dubletten mergen/entfernen

• Referenzen in Bewegungen anpassen

Standardisierung:

• Adressformate

• Telefonformate

• Schreibweisen/Namenskonventionen

• Mengeneinheiten

• Codes

Anreicherung:

• Fehlende Pflichtfelder ergänzen

• Teilrecords vervollständigen

• USt-IdNr. ergänzen (B2B)

• Adressen verifizieren

• Artikel kategorisieren

Korrektur/Validierung:

• Offensichtliche Fehler korrigieren

• Gegen externe Quellen validieren

• Rechenfehler beheben

• Datumsinkonsistenzen bereinigen

• Unplausible negative Werte prüfen

Obsolete Daten behandeln:

• Inaktive Kunden/Lieferanten markieren

• Auslaufartikel archivieren

• Testdaten separieren

Transformation:

• Legacy-Codes in BC-Konventionen übersetzen

• Kategorien auf neue Taxonomie mappen

• Datentypen konvertieren

• Hierarchien neu strukturieren

Cleansing-Workflow:

1. Quelle extrahieren (Staging)

2. Profiling durchführen

3. Regeln/Transformationen definieren

4. Automatisiert bereinigen

5. Ausnahmen manuell prüfen

6. Rest manuell korrigieren

7. Datenqualität validieren

8. Entscheidungen/Regeln dokumentieren

Tools:

• Excel (einfach)

• SQL-Skripte (Bulk)

• Data-Quality-Tools (z. B. OpenRefine)

• Skripte (Python/PowerShell)

• Business-Central-Importvalidierung

Data Mapping: Methodik

Definieren Sie präzise, wie Quelldaten auf Business-Central-Strukturen abgebildet werden.

Mapping-Dokumentation:

Struktur je Business-Central-Entität:

Entitätsinfo:

• Business-Central-Tabellenname

• Importmethode (RapidStart, Excel, API, custom)

• Lade-Reihenfolge

• Abhängigkeiten

Field Mappings:

Transformationsregeln:

Lookup-Tabellen:

Beispiel: Payment Terms Mapping

Mapping validieren:

• Sample-Konvertierung

• Edge Cases

• Null-Handling

• Datentyp-Kompatibilität

• Längen-/Format-Constraints

• Business-Regeln

Stammdatenmigration

Zuerst migrieren Sie die Grundlagen, die Transaktionen ermöglichen.

Kunden- und Lieferantenmigration

Kundenstamm

Kritische Felder:

• Kundennummer (eindeutig)

• Name/Suchname

• Adressen (Bill-to, Ship-to)

• Kontakte (Telefon, E-Mail, Website)

• Customer Posting Group

• Gen. Business Posting Group

• VAT/USt. Business Posting Group

• Payment Terms

• Währung

• Kreditlimit

• Blocked-Status

Wichtige optionale Felder:

• Verkäufercode

• Customer Price Group

• Customer Discount Group

• Shipping Agent

• Default Location

• Default-Dimensionen

• Payment Method

• Language Code

Kundenkontakte:

• Name/Titel

• Direkte Kontaktdaten

• Rolle

• Primary Contact

Ship-to Adressen:

• Zusätzliche Lieferorte

• Adressdetails

• Kontakte

• Standortbezogene Settings

Best Practices Kunden:

• Dubletten konsequent eliminieren

• Namenskonventionen standardisieren

• Adressen validieren (ggf. Services nutzen)

• USt-IdNr. für B2B vollständig

• Kreditlimits sinnvoll setzen

• Inaktive Kunden blocken

• Nummernkonvention sauber definieren

Lieferantenstamm

Ähnlich zu Kunden:

• Lieferantennummer

• Name/Suchname

• Adresse/Kontakt

• Vendor Posting Group

• Payment Terms/Methods

• Währung

• Default-Dimensionen

• Steuerdaten

Lieferantenspezifisch:

• Bevorzugte Zahlungsart

• Remittance-E-Mails

• Einschränkungen „Purchase from Vendor“

• Ratings/Bewertungen

• Laufzeiten (Versicherung/Lizenzen) – falls genutzt

Artikel- und Bestandsmigration

Artikelstamm (Item Master)

Essenzielle Felder:

• Artikelnummer (eindeutig)

• Beschreibung/Description 2

• Basismengeneinheit

• Artikelkategorie

• Typ (Inventory/Service/Non-Inventory)

• Bewertungsmethode (FIFO, Average, Standard, Specific)

• Einstandspreis/Verkaufspreis

• Gen. Product Posting Group

• Inventory Posting Group

• VAT/USt. Product Posting Group

• Replenishment System

• Primärlieferant

Bestandsrelevante Felder:

• Meldebestand

• Bestellmenge

• Lieferzeit

• Sicherheitsbestand

• Losgröße

• Tracking Code (Charge/Serie)

Fertigung (falls relevant):

• Production BOM

• Routing

• Manufacturing Policy

• Rescheduling Policy

• Order Tracking

Kategorien/Attribute/Varianten:

• Kategorien zuweisen

• Attribute definieren

• Varianten anlegen

• UoM-Umrechnungen definieren

Bestandsmengen (Eröffnungsbestände):

Option 1: Item Journal Entry

• Ein Journalposten pro Artikel/Standort

• Menge und Wert

• Zum Cutover gebucht

• Einfachster Ansatz

Option 2: Detailhistorie

• Import historischer Lagerbewegungen

• Audit Trail

• Chargen/Serien-Historie

• Komplexer, aber umfassend

Bestandsvalidierung:

• Mengen gegen physische Zählung abstimmen

• Bewertung prüfen

• Lot/Serial-Zuordnung prüfen

• Abgleich mit GL-Balances

Best Practices Artikel:

• Beschreibungen standardisieren

• Nummernschema definieren

• Obsolete/Dubletten entfernen

• Kategorisierung vor Migration fertigstellen

• UoM sehr sorgfältig prüfen

• Bewertungsmethode strategisch wählen

• Barcode-Anforderungen berücksichtigen

Anlagenmigration

Anlagenstamm (Fixed Assets)

Kritische Felder:

• Anlagennummer

• Beschreibung/Description 2

• FA Class/Subclass

• FA Location

• Verantwortliche Person

• Anschaffungsdatum und -kosten

• Depreciation Book Code

• Abschreibungsmethode

• Beginn Abschreibung

• Nutzungsdauer

• Prozentsatz

• Restbuchwert

• Restwert

Depreciation Books:

• Unterschiedliche Bücher (Tax vs. Financial)

• Integration in GL

• Parameter für Berechnung

Best Practices Anlagen:

• Anschaffungsdaten/-kosten prüfen

• Kumulierte Abschreibung abstimmen

• Restnutzungsdauer validieren

• Mehrere Bücher bei Bedarf

• Locations/Verantwortliche zuweisen

• Nummerierung/Kategorisierung definieren

• Laufende Abschreibung nach Go-Live planen

Kontenplan und GL-Balances

Sachkonten sind oft eher Konfiguration – Datenmigration umfasst häufig:

• Eröffnungsbestände zum Go-Live

• Optional: historische Details (Trends)

• Budgets

Eröffnungsbestände

Zeitpunkt: Letzte geschlossene Periode vor Go-Live

Vorgehen:

1. Saldenliste/Trial Balance aus Altsystem ziehen

2. Konten auf BC-Kontenplan mappen

3. Eröffnungsjournal erstellen

4. Dimensionen einbeziehen (falls nötig)

5. Debits = Credits sicherstellen

6. Zum Cutover buchen

Historische GL-Details (optional):

• Originalbuchungsdaten erhalten

• Belegnummern/Quellbelege erhalten

• Dimensionen übernehmen

• Periodensummen gegen Trial Balance validieren

• Für ältere Perioden ggf. Summenbuchungen statt Voll-Detail

RapidStart und Konfigurationspakete

Business Central bietet Migrationstools, die Imports strukturieren.

RapidStart – Überblick:

• Template-basierte Definition

• Excel-basierte Vorbereitung

• Validierung vor Import

• Batch-Import

• Fehlerhandling

Prozess Konfigurationspaket:

1. Package erstellen:

• Code/Beschreibung

• Tabellen auswählen

• Felder wählen

• Reihenfolge

• Validierungsregeln

2. Export nach Excel:

• Excel-Template erzeugen

• Validierungsregeln enthalten

• Feldbeschreibungen enthalten

3. Excel befüllen:

• Daten übernehmen

• Transformationen anwenden

• Regeln prüfen

4. Import nach Business Central:

• Excel importieren

• Fehler prüfen/korrekturen

• Package anwenden

5. Import validieren:

• Importlog prüfen

• Record Counts prüfen

• Stichproben

• Beziehungen prüfen

Best Practices RapidStart:

• Mit kleinen Pilotpaketen starten

• In Sandbox testen

• Field Mapping nutzen

• Data Templates nutzen

• Sequenz beachten (Masters vor Transactions)

• Excel-Dateien als Dokumentation aufbewahren

Sequenz (Beispiel):

1. Allgemeine Setups (Währungen, Zahlungsbedingungen, Spediteur)

2. Posting Groups

3. Kunden/Lieferanten

4. Artikel

5. Kontenplan

6. Offene Dokumente

7. Eröffnungsbestände

Excel-Templates und Import-Tools

Alternative Importmethoden je nach Use Case.

Excel-basierte Methoden:

Configuration Packages: Für strukturierte, wiederholbare Imports

Edit in Excel:

• Direktes Bearbeiten in Excel mit Synchronisierung

• Für kleine Updates

• Für einfache Entitäten

CSV-Import (Data Migration):

• Standard-CSV-Templates für bestimmte Entitäten

API-Import:

• Programmgesteuert

• Für große Volumina/komplexe Logik

• Automatisierbar

• Benötigt Development Skills

Tool-Auswahl (Daumenregel):

Testphasen für die Datenmigration

Konsequentes Testen verhindert Probleme im Cutover.

Phase 1: Unit Tests

Einzelentitäten isoliert testen:

• Einzelner Kunde

• Einzelner Lieferant

• Kleines Artikelset

• Beispieltransaktionen

Validierung:

• Format korrekt

• Mapping korrekt

• Defaults korrekt

• Regeln eingehalten

Phase 2: Integrationstests

Zusammenhängende Entitäten testen:

• Kunden inkl. Ship-to/Contacts

• Artikel inkl. Bestände

• Transaktionen mit Stammdaten

• GL inkl. Eröffnungsbeständen und Dimensionen

Validierung:

• Beziehungen intakt

• Referenzen korrekt

• Berechnungen korrekt

• Konsistenz

Phase 3: Volumentests

Mit realistischen Datenmengen testen:

• Voller Kunden-/Lieferantenbestand

• Gesamter Artikelkatalog

• Historie (falls migriert)

• GL-Details

Validierung:

• Performance

• Ressourcen

• Importdauer

• Integrität

Phase 4: User Acceptance Testing (UAT)

Fachbereiche validieren:

• Stichproben Kunden

• Artikel prüfen

• Offene Aufträge prüfen

• Finanzsalden bestätigen

Validierung:

• Vertrauen der Nutzer

• Nutzbarkeit

• Vollständigkeit

• Korrekturen

Best Practices Testing:

• Nur in Sandbox testen

• Produktionsnahe Datenmengen

• Fehler systematisch dokumentieren

• Nach Korrekturen retesten

• Formales Sign-off vor Cutover

• Testlogs sauber führen

Cutover-Planung und Umsetzung

Die finale Migration in Produktion erfordert disziplinierte Planung.

Cutover-Plan – Bausteine:

Vor Cutover (Tage/Wochen vorher):

• Finales Cleansing

• Finales Mapping

• Probeläufe in Sandbox

• Runbook finalisieren

• Go/No-Go-Kriterien

• Kommunikation

• Backups prüfen

• Ressourcen bestätigen

Cutover-Wochenende/-Zeitfenster:

Stunde 0–2: Freeze und finale Extraktion

• Legacy-System einfrieren

• Finaldaten extrahieren

• Letzte Quality Checks

• Daten für Import stage

Stunde 2–6: Datenimport

• Stammdaten importieren

• Offene Vorgänge importieren

• Eröffnungsbestände buchen

• Importlogs prüfen

• Fehler korrigieren

Stunde 6–10: Validierung und Abstimmung

• Record Counts verifizieren

• Schlüssel-Salden prüfen

• Abgleich mit Legacy

• Sample-Transaktionen testen

• User-Access prüfen

Stunde 10–12: Go-Live-Vorbereitung

• Smoke Tests

• Nutzer informieren

• Produktion freischalten

• Monitoring starten

Nach Cutover:

• Hypercare

• Monitoring

• Issue-Tracking

• Tägliche Abstimmungen

• Legacy-Archivierung nach Stabilisierung

Cutover-Runbook:

Step-by-Step inkl.:

• Dauer je Aktivität

• Verantwortlicher

• Voraussetzungen

• Konkrete Procedures

• Validierungs-Checkpoints

• Rollback (falls nötig)

• Kommunikationsregeln

• Eskalationskontakte

Beispiel Runbook Entry:

Eröffnungsbestände

Eröffnungsbestände definieren Ihren Startpunkt in Business Central.

Finanz-Eröffnungsbestände:

Trial Balance Import:

• Trial Balance aus Legacy

• Mapping auf BC-Kontenplan

• Dimensionen einschließen

• General Journal erstellen

• Debits/Credits ausgleichen

• Zum Go-Live-Datum buchen

Debitoren-Eröffnungsbestände:

Ansatz 1: Detail

• Jede offene Rechnung importieren

• Ermöglicht Aging Reports

• Fälligkeiten/Konditionen bleiben

Ansatz 2: Summen

• Ein Saldo je Kunde

• Schnell, weniger Detail

• Sinnvoll, wenn Detail nicht gebraucht wird

Kreditoren-Eröffnungsbestände:

• Analog: Detail je Rechnung oder Summensaldo je Lieferant

Bestandseröffnungsbestände:

• Menge je Artikel/Standort

• Wert

• Lot/Serial (falls Tracking)

• Via Item Journal

Best Practices:

• Gegen Trial Balance abstimmen

• Kunden-/Lieferantensalden mit Statements abgleichen

• Physische Inventur für Mengen

• Stichtag klar dokumentieren

• Legacy-Salden sichern (Backup)

• Abgleich mit steuerlichen/statutären Meldungen

Archivierung der Legacy-Daten

Planen Sie den Zugriff auf Daten, die nicht migriert werden.

Read-only Legacy:

• Legacy-System lesbar halten

• Für Nachfragen/Audits

• Retention definieren

Export und Archiv:

• Datenbank in neutrales Format exportieren

• Zugänglich speichern

• Struktur/Beziehungen dokumentieren

• User Guide für Zugriff

Report-Archiv:

• Wichtige historische Reports als PDF sichern

• Indizieren

• Finanzabschlüsse, Steuerreports, Auditreports

Timeline:

Sofort (Go-Live):

• Read-only Legacy

• Vollbackup

Kurzfristig (3–6 Monate):

• Stabilität prüfen

• Keine kritischen Gaps

• Legacy leicht zugänglich

Mittelfristig (6–12 Monate):

• Offline-Archiv

• Legacy dekommissionieren

• Prozess für Datenanfragen

Langfristig (1+ Jahre):

• Sicheres Storage

• Jährliche Zugriffstests

• Retention-Policies einhalten

Best Practices Archiv:

• Rechtliche Retention einhalten

• Lesbarkeit sicherstellen

• Inhalte/Zugriff dokumentieren

• Restore periodisch testen

• Archiv sicher schützen

Deliverables: Ergebnisse der Migrationsphase

1. Datenmigrationsplan

• Scope und Ansatz

• Inventar der Quellsysteme

• Cutover-Strategie und Timing

• Ressourcen

• Risiko- und Maßnahmenplan

2. Data-Mapping-Workbooks

• Field-Level-Mappings

• Transformationsregeln

• Validierungsregeln

• Lookup-Tabellen

3. Validierungs-Checkliste

• Unit-Test-Cases

• Integrationstestfälle

• Volumentestergebnisse

• UAT-Sign-off

4. Cutover-Runbook

• Pre-Cutover-Aktivitäten

• Cutover-Prozeduren

• Validierungs-Checkpoints

• Rollback-Prozeduren

Fazit: Von Legacy zu Business Central

Datenmigration ist die Brücke, die Ihre Unternehmenshistorie in die Business-Central-Zukunft trägt. Mit einem methodischen Ansatz – Datenqualität, konsequentes Testen und saubere Umsetzung – erhalten Sie verlässliche Daten, mit denen Ihr Team sicher produktiv arbeiten kann.

Key Takeaways:

✓ Strategisch planen: Vollständigkeit vs. Pragmatismus – nicht alles muss migriert werden

✓ Gründlich bereinigen: Data Quality entscheidet über Erfolg

✓ Präzise mappen: Jede Transformation dokumentieren

✓ Rigoros testen: Mehrere Testphasen vor Produktion

✓ Methodisch ausführen: Runbook diszipliniert abarbeiten

✓ Umfassend validieren: Alles gegen das Legacy-System abstimmen

Mit sauberen Daten in Ihrer konfigurierten Business-Central-Umgebung folgt als nächste Phase: Anpassungen, Erweiterungen & Integrationen – dort erweitern Sie Business Central gezielt für individuelle Anforderungen.

Nächster Artikel in der Serie: Blog 5: Anpassungen, Erweiterungen & Integrationen – So erweitern Sie Business Central per AL-Erweiterungen, AppSource und Integrationen.

Download-Ressourcen:

• Datenmigrationsplan-Vorlage

• Data-Mapping-Worksheet

• Cutover-Runbook-Vorlage

• Validierungs-Checkliste

Fragen oder Kommentare? Teilen Sie Ihre Erfahrungen und Lessons Learned zur Datenmigration gern in den Kommentaren.

Dies ist Teil 4 einer 8-teiligen Serie zur Business-Central-Implementierung. Abonnieren Sie, um Benachrichtigungen zu neuen Artikeln zu erhalten.

Tags: #BusinessCentral #Datenmigration #ERP #ERPImplementierung #DataQuality #Dynamics365 #Migrationsstrategie