Ratgeber · KI
Von Dynamics NAV nach Business Central: Was mitmuss und was nicht
Der technische Weg von Dynamics NAV nach Business Central ist dokumentiert und planbar. Die eigentliche Frage lautet: Welche Daten und Prozesse müssen den Systemwechsel überleben, in welcher Form und mit welchem Nachweis? Wer diese Frage erst am Wochenende des Wechsels stellt, hat sie schon falsch beantwortet. Dieser Ratgeber zeigt den Upgrade-Pfad, drei Wege für Altdaten und wie Sie prüfen, dass alles richtig angekommen ist.
Der Upgrade-Pfad ist gelöst, die Datenfrage nicht
Der Zeitdruck ist real. Der Extended Support für Dynamics NAV 2017 endet am 11. Januar 2027, für NAV 2018 am 11. Januar 2028. NAV 2016 ist seit dem 14. April 2026 ohne Support, NAV 2015 seit dem 14. Januar 2025. Mehr dazu im Ratgeber Dynamics NAV Supportende.
Microsoft beschreibt den Pfad eindeutig: Von NAV 2015 bis 2018 führt der Weg über Business Central Version 14, dann Version 25, dann die aktuelle Version 29. Alle C/AL-Anpassungen müssen dafür zu AL-Erweiterungen werden, sonst lassen sich die Daten der betroffenen Tabellen nicht übernehmen. Daneben bietet Microsoft ein Werkzeug für einen Neuaufbau, das Stammdaten, offene Vorgänge und Eröffnungssalden überträgt, nicht aber die vollständige Buchungshistorie. Welcher Weg passt, ist eine Entscheidung, die man nicht nebenbei trifft.
Aufbewahren heißt nicht produktiv vorhalten
Steuer- und handelsrechtliche Aufbewahrungspflichten verlangen, dass Unterlagen über die vorgeschriebene Frist verfügbar und auswertbar bleiben. Sie schreiben aber kein bestimmtes System vor. Daraus folgt: Die Daten müssen vollständig und in vertretbarer Zeit auffindbar sein, nicht zwingend im produktiven ERP liegen. Diese Unterscheidung ist der größte Hebel des Projekts. Stimmen Sie die Details mit Ihrem Steuerberater oder Wirtschaftsprüfer ab.
Drei Wege für Altdaten
Für jeden Datenbestand gibt es drei Optionen: übernehmen, neu aufbauen oder kontrolliert archivieren. Der Reflex „wir nehmen alles mit“ ist die teuerste Variante. Jede übernommene Tabelle muss zugeordnet, getestet und nach dem Umzug geprüft werden, und eine Datenbank voller gewachsener Widersprüche macht das neue System nicht besser.
Offene Posten, aktuelle Bestände, laufende Aufträge
Grund: Operativ ab Tag eins nötig
Empfohlener Weg: Übernehmen
Chargen- und Seriennummernhistorie aktiver Artikel
Grund: Rückverfolgung und Reklamationen
Empfohlener Weg: Übernehmen
Gesperrte Artikel und Chargen mit Sperrgrund
Grund: Keine stillschweigende Freigabe
Empfohlener Weg: Übernehmen, mit Abgleich Zeile für Zeile
Historie ausgelaufener Artikel und alte Belege
Grund: Aufbewahrungspflicht, kein täglicher Zugriff
Empfohlener Weg: Kontrolliert archivieren
Artikelstammdaten, Nummernkreise, Attribute
Grund: Das alte Datenmodell ist oft selbst die Altlast
Empfohlener Weg: Neu aufbauen
C/AL-Anpassungen ohne Prozessbezug
Grund: Kein fachlicher Zweck benennbar
Empfohlener Weg: Streichen
Sperrlogik: der leise, teure Fehler
Der teuerste Fehler dieser Projekte fällt nicht auf: Eine gesperrte Charge entsteht im Zielsystem ohne Sperrkennzeichen und ist damit ab Tag eins verkaufsfähig. Das passiert vor allem bei Neuaufbau und manueller Datenübernahme. Business Central kennt Sperren auf mehreren Ebenen, auf dem Artikel für Verkauf, Einkauf, Produktion und Service und auf der einzelnen Charge. Diese Ebenen sind nicht austauschbar. Wer eine NAV-Sperrlogik migriert, braucht deshalb eine Abbildungsregel je Sperrgrund und eine vollständige Gegenprüfung nach dem Umzug, keine Stichprobe.
Stammdaten: der letzte günstige Zeitpunkt
Der Systemwechsel ist der beste und zugleich der letzte günstige Zeitpunkt, das Artikelstammdatenmodell zu bereinigen. Danach kostet jede Änderung Abstimmung und Test. Varianten, Artikelreferenzen und Attribute gehören in ein sauberes Modell, nicht in freie Textfelder. Microsoft verlangt vor der Migration ohnehin eine Bereinigung: Unzulässige Zeichen in Code-Feldern müssen vorher entfernt werden, sonst schlagen spätere Zugriffe auf diese Felder in der Cloud fehl.
Anpassungen: Was war je ein Geschäftsprozess?
Jede C/AL-Anpassung muss zu einer AL-Erweiterung werden. Das erzwingt eine Frage, die jahrelang niemand stellen musste: Welcher Teil davon war je ein Geschäftsprozess und welcher nur Gewohnheit? Ein Teil der Anpassungen bildet Anforderungen ab, die der Standard heute abdeckt. Der Prüfmaßstab ist einfach: Für jede Anpassung muss benannt werden, welche Anforderung sie erfüllt und was ihr Wegfall bedeuten würde. Was diesen Maßstab nicht erfüllt, wird nicht übertragen.
Nachweisen, dass alles angekommen ist
Die Migration selbst ist eine kontrollierte Änderung. Sie braucht einen Plan, Abnahmekriterien und einen Nachweis, dass die Daten nach dem Umzug vollständig und korrekt sind. Microsoft empfiehlt, mindestens zwei Probeläufe in einer Sandbox vor dem produktiven Wechsel einzuplanen, mit gemessenen Laufzeiten und fachlicher Abnahme. Das Minimum: Mengen- und Summenabgleich je wichtiger Tabelle, Stichproben entlang vollständiger Ketten vom Wareneingang bis zum Kunden, Vollprüfung aller Sperrzustände und ein Migrationsbericht mit Quelle, Ziel, Abweichung und Entscheidung.
Wo KI-Agenten hier helfen
Eine NAV-Migration besteht zu großen Teilen aus Prüf- und Abgleicharbeit. Die lässt sich automatisieren.
• Anpassungen bewerten: Ein Agent liest die C/AL-Objekte und schlägt je Anpassung vor, welchen Zweck sie hat und ob der Standard von Business Central sie heute abdeckt. Ihr Team entscheidet, was übertragen wird.
• Stammdaten bereinigen: Dubletten, unzulässige Zeichen und unvollständige Datensätze werden vor der Migration automatisch gefunden und als Liste zur Bereinigung vorgelegt.
• Abgleich und Bericht: Ein Ablauf vergleicht nach jedem Probelauf Mengen, Summen und Sperrzustände zwischen NAV und Business Central und erstellt den Migrationsbericht.
Nach dem Wechsel stehen in Business Central auch die Agenten von Microsoft bereit, etwa der Payables Agent für Eingangsrechnungen. Mehr dazu im Ratgeber Release Wave 2 2026.
Wo aenuma hilft
aenuma begleitet den Weg von NAV nach Business Central bei Bestandsaufnahme, Datenstrategie und der Steuerung Ihres Implementierungspartners und baut die KI-Agenten, die Prüfung und Abgleich übernehmen. Mehr dazu auf der Seite Leistungen.
Häufige Fragen
Müssen wir die komplette Historie aus NAV übernehmen?
Nein. Sie müssen sie aufbewahren und auswertbar halten, das ist nicht dasselbe wie produktiv vorhalten. Historie zu aktiven Artikeln gehört ins System, alte Belege können kontrolliert archiviert werden, sofern der Zugriffsweg dokumentiert und erprobt ist.
Was passiert mit gesperrten Chargen beim Übergang?
Beim technischen Upgrade kommen die Kennzeichen mit. Bei Neuaufbau oder manueller Übernahme passiert ohne Abbildungsregel das Falsche: Die Chargen kommen ohne Sperrkennzeichen an und sind sofort verwendbar.
Was wird aus unseren C/AL-Anpassungen?
Sie müssen als AL-Erweiterungen vorliegen, sonst lassen sich die Daten der betroffenen Tabellen nicht übernehmen. Nutzen Sie den Zwang zur Übertragung als Prüfung: Jede Anpassung ohne benennbare Anforderung wird gestrichen statt übersetzt.
Wie weisen wir nach, dass die Daten korrekt angekommen sind?
Über einen vorab definierten Prüfplan mit Abnahmekriterien, mindestens zwei Probeläufe in der Sandbox und einen Migrationsbericht mit Abgleich und dokumentierten Abweichungen. Der Nachweis entsteht vor dem Wechsel, nicht danach.
Quellen
Supported upgrade paths to Business Central releases (Microsoft Learn)
Migrate Dynamics NAV to Business Central online (Microsoft Learn)
Prepare and plan for cloud migration (Microsoft Learn)
Clean data before cloud migration (Microsoft Learn)
Trace item-tracked items (Microsoft Learn)
Block items or item variants (Microsoft Learn)
Ending Support in 2027 (Microsoft Learn)
Von Joshua Schütt, Gründer von aenuma. Stand: November 2026.
Planen Sie den Wechsel auf Business Central?
Erzählen Sie uns, welche NAV-Version Sie betreiben und welche Daten Ihnen Sorgen machen. Wir sagen Ihnen, welcher Weg passt und welche Prüfarbeit sich automatisieren lässt.
Anwendungsfall besprechen