Guide · AI
From Dynamics NAV to Business Central: What to Bring and What to Leave
The technical path from Dynamics NAV to Business Central is documented and predictable. The real question is: which data and processes need to survive the switch, in what form and with what evidence? If you only ask that on cutover weekend, you have already answered it wrong. This guide covers the upgrade path, three ways to handle legacy data, and how to verify that everything arrived correctly.
The upgrade path is solved, the data question is not
The time pressure is real. Extended support for Dynamics NAV 2017 ends on January 11, 2027, for NAV 2018 on January 11, 2028. NAV 2016 has been out of support since April 14, 2026, NAV 2015 since January 14, 2025. More in Dynamics NAV end of support.
Microsoft describes the path clearly: from NAV 2015 through 2018, it runs via Business Central version 14, then version 25, then the current version 29. All C/AL customizations have to become AL extensions, otherwise the data in the affected tables cannot be migrated. Microsoft also offers a tool for a fresh start that transfers master data, open documents and opening balances, but not the full posting history. Which route fits is not a decision to make in passing.
Retaining data is not the same as keeping it live
Tax and commercial retention rules require records to stay available and readable for the required period. They do not prescribe a specific system. So the data has to be complete and findable within a reasonable time, not necessarily inside the live ERP. That distinction is the biggest lever in the project. Confirm the details with your tax advisor or auditor.
Three ways to handle legacy data
For each data set there are three options: migrate, rebuild or archive under control. The reflex to "bring everything" is the most expensive option. Every migrated table has to be mapped, tested and checked after the move, and a database full of accumulated contradictions does not make the new system better.
Open entries, current inventory, running orders
Reason: Needed from day one
Recommended route: Migrate
Lot and serial number history for active items
Reason: Traceability and complaints
Recommended route: Migrate
Blocked items and lots with block reason
Reason: No silent release
Recommended route: Migrate, with line-by-line reconciliation
History of discontinued items and old documents
Reason: Retention requirement, no daily access
Recommended route: Archive under control
Item master data, number series, attributes
Reason: The old data model is often the legacy problem
Recommended route: Rebuild
C/AL customizations without a process purpose
Reason: No business purpose can be named
Recommended route: Drop
Block logic: the quiet, expensive mistake
The most expensive mistake in these projects goes unnoticed: a blocked lot arrives in the target system without its block flag and is sellable from day one. This happens mainly with a rebuild or manual data transfer. Business Central has blocks on several levels, on the item for sales, purchasing, production and service, and on the individual lot. These levels are not interchangeable. Migrating NAV block logic therefore needs a mapping rule per block reason and a complete cross-check after the move, not a sample.
Master data: the last cheap moment
The switch is the best and also the last cheap moment to clean up the item master data model. After that, every change costs coordination and testing. Variants, item references and attributes belong in a clean model, not in free text fields. Microsoft requires cleanup before migration anyway: invalid characters in code fields have to be removed first, or later access to those fields fails in the cloud.
Customizations: what was ever a business process?
Every C/AL customization has to become an AL extension. That forces a question nobody had to ask for years: which part was ever a business process and which part just habit? Some customizations cover requirements the standard product handles today. The test is simple: for each customization, name the requirement it meets and what dropping it would mean. Whatever fails that test is not carried over.
Proving that everything arrived
The migration itself is a controlled change. It needs a plan, acceptance criteria and evidence that the data is complete and correct after the move. Microsoft recommends planning at least two dry runs in a sandbox before the production cutover, with measured run times and business sign-off. The minimum: quantity and total reconciliation per key table, samples along complete chains from goods receipt to customer, a full check of all block states, and a migration report with source, target, deviation and decision.
Where AI agents help here
A NAV migration is largely checking and reconciling. That can be automated.
• Assess customizations: An agent reads the C/AL objects and proposes the purpose of each customization and whether Business Central's standard covers it today. Your team decides what gets carried over.
• Clean up master data: Duplicates, invalid characters and incomplete records are found automatically before the migration and listed for cleanup.
• Reconcile and report: After each dry run, a workflow compares quantities, totals and block states between NAV and Business Central and produces the migration report.
After the switch, Microsoft's own agents are available in Business Central too, such as the Payables Agent for incoming invoices. More in Release Wave 2 2026.
How aenuma helps
aenuma supports the move from NAV to Business Central with inventory, data strategy and steering your implementation partner, and builds the AI agents that handle checking and reconciliation. More on our services page.
Frequently asked questions
Do we have to migrate the full history from NAV?
No. You have to retain it and keep it readable, which is not the same as keeping it live. History for active items belongs in the system; old documents can be archived under control, as long as the access path is documented and tested.
What happens to blocked lots during the switch?
With the technical upgrade, the flags come along. With a rebuild or manual transfer, the wrong thing happens without a mapping rule: lots arrive without their block flag and are usable right away.
What happens to our C/AL customizations?
They have to exist as AL extensions, otherwise the data in the affected tables cannot be migrated. Use this as a review: every customization without a nameable requirement gets dropped instead of translated.
How do we prove the data arrived correctly?
With a test plan and acceptance criteria defined up front, at least two dry runs in a sandbox, and a migration report with reconciliation and documented deviations. The evidence is created before the cutover, not after.
Sources
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)
By Joshua Schütt, founder of aenuma. Last updated: November 2026.
Planning your move to Business Central?
Tell us which NAV version you run and which data worries you. We will show you which route fits and which checking work can be automated.
Book a call