Datenmigration nach Business Central: was ist zu beachten?

Eine Datenmigration nach Business Central gelingt in vier Schritten: Erst entscheiden, was überhaupt migriert wird, denn Historie gehört selten dazu. Dann die Stammdaten bereinigen, bevor sie das neue System erreichen. Dann in Testläufen migrieren, mit Abstimmung gegen die Altbilanz. Zum Schluss der Echtlauf mit festem Datenstichtag. Wer Altlasten unbereinigt übernimmt, migriert seine Probleme mit.

Was wird migriert, und was bewusst nicht?

Der Standardumfang ist kleiner, als viele erwarten: Stammdaten wie Kunden, Lieferanten, Artikel und Sachkonten, dazu offene Posten, offene Belege und Bestände zum Stichtag, plus Eröffnungssalden. Das reicht für einen sauberen Start.

Bewegungshistorie gehört in den meisten Fällen nicht ins neue System. Sie verstopft die Datenbasis mit Alt-Strukturen und kostet in der Migration ein Vielfaches des Nutzens. Für Auswertungszwecke bleibt die Historie im Altsystem lesbar oder wandert in ein Archiv beziehungsweise ein Reporting-Modell. Ausnahmen gibt es, etwa gesetzliche Anforderungen oder Seriennummern-Rückverfolgung, aber sie sollten begründet werden, nicht der Reflex sein.

Die Trennung folgt einer einfachen Frage: Braucht das Tagesgeschäft diesen Datensatz, oder braucht ihn nur die Nachvollziehbarkeit? Das Erste geht live, das Zweite in ein Archiv, aus dem im Bedarfsfall gelesen wird, ohne das neue System zu belasten.

Warum ist die Bereinigung wichtiger als das Werkzeug?

Ob per Konfigurationspaket, RapidStart oder Migrationstool: Der technische Transport ist gelöst. Was Projekte verzögert, sind Dubletten im Kundenstamm, Artikel ohne Pflege-Verantwortung, Kreditoren mit drei Schreibweisen und Konten, die seit Jahren als Sammelbecken dienen.

Deshalb gilt die Reihenfolge: erst bereinigen, dann migrieren. Ein neues System verbessert die Datenqualität nicht automatisch, es macht sie sichtbar. Die Migration ist die beste Gelegenheit seit Jahren, die Datenbasis auf den Stand zu bringen, den das Geschäft braucht, und sie kommt so schnell nicht wieder.

Werkzeuge lösen zuverlässig das Transportproblem, aber eben nicht das Bedeutungsproblem. Ob ein Feld für den vorgesehenen Zweck genutzt wurde oder über Jahre für etwas anderes, sieht kein Werkzeug, und genau diese Klärung ist der Aufwand, der Migrationsprojekte am Ende deutlich verlängert.

Wie läuft eine Migration konkret ab?

• Umfang festlegen: welche Datenobjekte, welcher Stichtag, welche Ausnahmen
• Mapping definieren: Altfelder auf Business-Central-Strukturen, inklusive Dimensionen
• Bereinigen im Altsystem oder im Zwischenschritt, mit benannten Verantwortlichen je Datenobjekt
• Mindestens zwei Testmigrationen mit Abstimmung: Summen, Salden, offene Posten gegen das Altsystem
• Echtlauf zum Stichtag, mit eingefrorenem Altsystem und dokumentierter Abstimmung

Die Testmigrationen sind der Punkt, an dem gespart wird und der sich am bittersten rächt. Erst der zweite Testlauf zeigt, ob Mapping und Bereinigung wirklich sitzen, weil der erste fast immer Überraschungen liefert. Wer direkt nach dem ersten Lauf live geht, verlegt den Test in den Echtbetrieb.

Der Testlauf ist der Schritt, der am häufigsten gestrichen wird, und der einzige, der die anderen absichert. Ohne ihn stellt sich erst am Migrationswochenende heraus, ob Salden und Bezüge stimmen, und dann fehlt die Zeit für eine geordnete Korrektur.

Wer trägt die Verantwortung für die Daten?

Nicht der Partner und nicht die IT, sondern der Fachbereich, dem die Daten gehören: Vertrieb für Kunden, Einkauf für Lieferanten, Produktmanagement für Artikel, Finanzen für Konten und Salden. Der Partner baut Werkzeuge und Mapping, aber ob ein Kunde eine Dublette ist, kann nur das Geschäft entscheiden.

Praktisch heißt das: je Datenobjekt eine benannte Person, die freigibt. Diese Freigaben sind keine Formalie, sie sind die Qualitätssicherung der künftigen Datenbasis, auf der später auch jede Automatisierung und jeder KI-Agent arbeitet.

Die Antwort lautet immer: der Fachbereich, nicht die IT. Die IT stellt Werkzeuge und Transport, aber ob ein Kundenstamm korrekt ist, kann nur beurteilen, wer mit diesen Kunden arbeitet. Ohne namentlich benannte Verantwortliche je Datenobjekt bleibt Datenqualität eine Sammelzuständigkeit, die niemand wirklich hat.