Business Central Datenmigration
Vollständig migriert, kein Datenverlust
Business Central Datenmigration aus SAP, Excel, Fremdsystemen: Stammdaten, offene Posten, Bewegungsdaten. RapidStart, Mapping, Validierung. Kein Overhead.
Wenn ein neues Business-Central-System eingeführt wird, gilt die meiste Aufmerksamkeit dem Setup: Buchungsgruppen konfigurieren, Workflows definieren, Reports anpassen, Benutzer schulen. Die Datenmigration landet oft am Ende der Projektplanung — als technische Aufgabe, die man kurz vor Go-live erledigt.
Das ist der häufigste Projektfehler bei BC-Einführungen.
Datenmigration ist kein Knopfdruck. Daten aus einem bestehenden ERP-System, aus Excel-Tabellen, aus SAP-Exporten oder aus einer alten Finanzbuchhaltung haben eigene Strukturen, eigene Schlüssel, eigene Konventionen. Business Central erwartet eigene Strukturen. Zwischen diesen beiden Welten liegt Mapping-Arbeit, Bereinigungsarbeit, Validierungsarbeit. Wer das unterschätzt, macht Go-live mit fehlendem Altdatenbestand — und arbeitet danach Monate parallel in zwei Systemen.
Als freiberuflicher Berater führe ich Business-Central-Datenmigrationsprojekte vollständig durch: von der Datenanalyse über das Mapping bis zur Validierung nach dem Import. Direkt, ohne Zwischenschicht, mit meiner vollen Verantwortung für das Ergebnis.
Jede Datenmigration beginnt mit der Bestandsaufnahme: Woher kommen die Daten? In welchem Format liegen sie vor? Wie vollständig sind sie? Welche Strukturunterschiede bestehen zu BC?
Ich analysiere euren Datenbestand — egal ob aus einem Legacy-ERP, aus SAP-Exporten, aus Excel-Tabellen oder aus einer älteren NAV-Installation — und erstelle ein Migrationskonzept mit klarem Scope: welche Daten werden migriert, in welcher Reihenfolge, mit welchen Transformationsregeln.
Konfigurationsdaten sind die Grundlage, auf der alles andere aufbaut. Sie müssen zuerst migriert werden.
Dazu gehören Debitoren- und Kreditorenstammdaten, Artikelstammdaten, Kontenpläne, Buchungsgruppen, Zahlungsbedingungen, Einheiten, Lagerorte, Kostenstellen. In Business Central werden diese Daten über RapidStart Services importiert — ein standardisiertes Migrationsframework, das Excel-basierte Importvorlagen für alle BC-Tabellen bereitstellt.
Typische Herausforderungen bei Stammdaten:
Bewegungsdaten sind das, was buchhalterisch zur Vollständigkeit der Migration entscheidet.
In der Regel werden nicht alle historischen Buchungen vollständig migriert — das wäre technisch aufwendig und selten notwendig. Stattdessen wird ein Stichtag definiert: Alle offenen Posten (offene Debitorenrechnungen, offene Kreditorenrechnungen, offene Banktransaktionen) werden migriert. Für abgeschlossene Perioden werden Eröffnungssalden auf Kontoebene übernommen.
Historische Buchungsdetails bleiben im Altsystem lesbar verfügbar — das ist der pragmatische Standard, den ich empfehle, solange das Altsystem nicht vollständig abgeschaltet wird.
Nicht jedes Unternehmen wechselt von NAV zu BC. Viele kommen aus völlig anderen ERP-Systemen oder aus Excel-basierten Prozessen.
Migration aus SAP: SAP-Exporte liegen meist als CSV oder in proprietären Formaten vor. Strukturunterschiede sind erheblich: SAP-Buchungslogik unterscheidet sich grundlegend von BC. Ich entwickle Transformationsskripte, die SAP-Exporte in BC-kompatible Importformate überführen — mit explizitem Mapping jedes Feldes.
Migration aus Excel: Viele Unternehmen führen Teile ihrer Buchhaltung oder Lagerverwaltung in Excel. Excel-Daten haben keine erzwungene Struktur — Inkonsistenzen, freie Texte in Feldern, die Zahlen erwarten, sind der Normalfall. Ich bereinige die Daten vor dem Import und dokumentiere jede Abweichung.
Migration aus anderen ERP-Systemen: Sage, Lexware, Diamant, Navision-Vorgänger, branchenspezifische Systeme — jedes hat eigene Exportmöglichkeiten. Ich analysiere die verfügbaren Exportformate und entwickle den Migrationspfad von dort.
Wenn Quellstruktur und Zielstruktur sich unterscheiden, braucht es ein Mapping. Das ist keine triviale Aufgabe: Buchungsgruppen im Quellsystem heißen anders als in BC, Kontonummern folgen einer anderen Logik, Lagerortkürzel passen nicht.
Ich erstelle eine vollständige Mapping-Dokumentation — jedes migrierte Feld, jede Transformationsregel, jede Ausnahme. Das Dokument wird Teil der Projektdokumentation und ist wichtig für spätere Nachvollziehbarkeit.
Nach jedem Importlauf folgt eine Validierung: Wurden alle Datensätze importiert? Stimmen Summen? Gibt es Differenzen zwischen Quellsystem und BC? Sind alle Pflichtfelder befüllt?
Ich führe strukturierte Abnahmetests durch — mit dem Fachbereich, nicht nur technisch. Erst wenn die Validierung sauber ist, gilt der Datenmigrations-Schritt als abgeschlossen.
Ihr braucht professionelle Unterstützung bei der BC-Datenmigration, wenn ihr:
Ein Handelsunternehmen wechselt von einem branchenspezifischen ERP zu Business Central. Der Datenbestand umfasst 4.200 Artikelstammdaten, 1.800 Debitoren, 620 Kreditoren, 14 Monate offene Posten und sieben Jahre historische Eröffnungssalden.
Die Artikelstammdaten liegen im Quellsystem mit einer Feldstruktur vor, die BC so nicht kennt. Drei Pflichtfelder in BC — Buchungsgruppe Artikel, Produktbuchungsgruppe, Einheitencode — fehlen im Quellsystem vollständig. Sie müssen vor dem Import angereichert werden.
Bei den Debitoren gibt es 312 Datensätze mit Zeichenkodierungsproblemen: Umlaute wurden beim Export als Fragezeichen gespeichert. Ein automatisierter Bereinigungsschritt korrigiert 287 Fälle; 25 werden manuell geprüft.
Das Ergebnis nach der Validierung: 100% der Stammdaten migriert, davon 98,6% vollautomatisch. Offene Posten stimmen auf Euro genau mit dem Quellsystem überein. Datenvollständigkeit ist die Kennzahl, auf die es ankommt — und sie ist am Ende messbar und dokumentiert.
Können historische Buchungen vollständig nach BC migriert werden?
Technisch ja — praktisch ist es selten sinnvoll. Vollständige Buchungshistorien aus mehreren Jahren zu migrieren ist aufwendig und macht das Zielsystem schwerer. Der pragmatische Ansatz: Eröffnungssalden auf Kontoebene und offene Posten migrieren, das Altsystem für historische Recherchen bis zum Ende der Aufbewahrungsfrist les-verfügbar halten. Wenn eine vollständige Migration notwendig ist — etwa aus Compliancegründen — ist das möglich, erfordert aber mehr Aufwand und explizite Planung.
Was, wenn unsere Quelldaten in schlechter Qualität vorliegen?
Das ist häufiger der Normalfall als die Ausnahme. Schlechte Datenqualität bedeutet mehr Bereinigungsaufwand — aber kein unüberwindliches Problem. Wichtig ist, den Zustand der Quelldaten früh in der Projektplanung zu kennen, damit der Aufwand realistisch eingeschätzt wird. Wer das erst kurz vor Go-live entdeckt, verliert Zeit.
Wie lange dauert eine Datenmigration?
Die Laufzeit hängt vom Datenvolumen, der Anzahl der Quelldaten-Formate und der Qualität der Quelldaten ab. Einfache Migrationen aus einer einzigen Quelle mit gut strukturierten Daten: zwei bis vier Wochen. Komplexe Migrationen aus mehreren Fremdsystemen mit Bereinigungsbedarf: sechs bis zehn Wochen. Die Analysephase zeigt, was realistisch ist.
Können wir die Datenmigration intern selbst durchführen?
RapidStart Services ist von Microsoft als Self-Service-Tool konzipiert. Technisch ist eine interne Migration möglich — wenn jemand die Zeit hat, sich einzuarbeiten, und wenn die Datenqualität gut ist. Das Problem: Fehler bei der Datenmigration fallen oft erst Wochen nach Go-live auf — wenn der Buchhaltungsabschluss nicht aufgeht oder Salden nicht stimmen. Die Kosten der Fehlerkorrektur übersteigen dann häufig die Kosten einer professionellen Durchführung.
Wie läuft das Erstgespräch ab?
30 Minuten. Du schilderst mir das Problem, ich sage dir ob und wie ich helfen kann — direkt, ohne Präsentation. Danach bekommst du eine schriftliche Einschätzung mit Aufwand und Vorgehen. Erst dann entscheidest du ob wir starten.
Datenanalyse vor Projekstart — ich schätze den Aufwand realistisch ein.
Kein Jahresvertrag. Kein Mindestvolumen. Du zahlst für das gelöste Problem.
Weitere Themen: Navision Migration Business Central · Business Central Implementierung
Über mich
Freiberuflicher BC-Entwickler und Consultant aus Bochum. Ich arbeite direkt mit eurem Fachbereich — ohne Agentur-Overhead, ohne Account-Staffelung. Remote und vor Ort in NRW verfügbar.
Mehr über mich und meine LeistungenSchreib mir eine Nachricht oder ruf direkt an.
