techone --guide=nav-to-bc
From Dynamics NAV to Dynamics 365 Business Central
The first decision is whether to retain the existing solution and follow the supported migration path, or implement Dynamics 365 Business Central as a new system with selected data. The source version, customizations, value of history, integrations, and target operation determine the route.
TL;DR
- The main decision
- Whether to retain the current database and follow a supported technical migration, or implement Dynamics 365 Business Central as a new system with selected processes and data.
- Supported path
- The standard route from Dynamics NAV 2015 through 2018 to the cloud uses Dynamics 365 Business Central version 14 and then version 25 or later. Older releases require more intermediate steps.
- New implementation
- A new target solution is configured and data moves through approved project-specific mappings. This is not a shortened form of the standard migration path.
- Support status
- Extended support for Dynamics NAV 2016 ended on April 14, 2026. Dynamics NAV 2017 ends on January 11, 2027, and Dynamics NAV 2018 on January 11, 2028.
- What to prepare
- The exact version, companies and databases, custom objects and code, integrations, reports, data volume, and requirements for accessible history.
Make the Decision Before the Migration Plan
The end of support indicates when technical and operational risk increases, but it does not determine the right route. Dynamics NAV can continue to run, while standard fixes become less available and the organization becomes more dependent on its specific version, infrastructure, and partner.
A technical migration retains continuity of the existing database and proceeds through supported intermediate releases. It can fit when history still has operational value, customizations remain necessary, and the relevant code can move to the current extension model. It can also carry technical debt forward unless each legacy function is reviewed before target design.
A new implementation creates the target processes and configuration again. Master data, open transactions, balances, and selected history move through separately designed imports and mappings. This is not an automatic shortcut through the standard migration path; its data scope, tests, and archive need their own specification.
Supported Path by Source Version
Current Microsoft documentation defines different routes by source version. Exact builds and compatible cumulative updates also need validation before delivery; the major version number alone is not sufficient.
Dynamics NAV 2015 through 2018
The standard route to Dynamics 365 Business Central online passes through version 14 on-premises and then version 25 or later. Converting the application from C/AL to AL is part of this route.
Dynamics NAV 2013 and 2013 R2
The solution first moves to Dynamics NAV 2018. Dynamics 365 Business Central version 14, version 25 or later, and the move to the online environment follow.
Dynamics NAV 2009 SP1 and 2009 R2
The route includes Dynamics NAV 2013 or 2015, then Dynamics NAV 2018, Dynamics 365 Business Central version 14, and version 25 or later before cloud migration.
Dynamics NAV 2016 through 2018 support
Extended support for Dynamics NAV 2016 ended on April 14, 2026. Dynamics NAV 2017 ends on January 11, 2027, and Dynamics NAV 2018 on January 11, 2028. The earlier releases listed here are already beyond extended support.
Intermediate releases are a technical prerequisite, not the complete project. Every step needs a compatible database, application, extensions, and a validated rollback method.
Technical Migration or New Implementation
The decision does not follow the age of Dynamics NAV alone. It depends on whether the organization needs continuity of the current solution or wants to change processes and leave some legacy customizations behind. Both routes can require substantial work; the location of the main effort and risk is different.
Value of complete history
A full technical migration is more suitable when users need extensive history and its relationships in the target environment. A new implementation selects the data required for operations and keeps the rest in a searchable archive.
Customizations and technical debt
Required C/AL customizations become AL extensions during technical migration. If much of the code duplicates current standard functionality or no longer matches operations, redesigning the functions can be more appropriate.
Target processes
Technical migration retains more continuity. A new implementation provides more room to align roles, approvals, dimensions, master data, and working practices, but requires firmer process decisions and user preparation.
Data and integrations
The number of companies, database size, custom tables, reports, banks, e-commerce, CRM, WMS, or EDI can change the decision. Every connection needs a data owner, target interface, and test scenario.
The assessment should produce a reasoned route, a defined data scope, and a decision list for customizations and integrations.
What Happens to Customizations, Data, and Integrations
Before designing the move, we inventory custom objects, fields, tables, reports, and connected systems. For each customization, the decision is whether current Dynamics 365 Business Central standard functionality covers it, a suitable application exists, an AL extension is needed, or the process should change.
Data scope follows the chosen route and actual use. Copying tables successfully is not enough. Balances and relationships must reconcile after transfer, and users need to complete the scenarios for which they are responsible.
C/AL code and custom objects
Full migration requires the necessary logic to become AL extensions. Automated tools can support part of the conversion, but a developer must resolve conflicts, replaced functions, and dependencies on standard code and then test the result.
Master data and open transactions
Customers, vendors, items, accounts, dimensions, open documents, and opening balances are cleaned, mapped, and approved by the owners of the relevant business areas.
History and custom tables
Technical migration can retain greater data continuity where target tables and extensions provide the corresponding structure. A new implementation selects history according to operational, accounting, and audit requirements.
Integrations, identities, and reports
Every connection is validated against its target interface and permissions. Design also covers Microsoft Entra accounts, user roles, document outputs, reports, and ownership of failed messages.
Controls and archive
Trial transfers compare record counts, relationships, and financial balances. The source system or its data remains available under an approved archive and rollback plan.
How the Project Runs
The sequence applies to both technical migration and a new implementation. The scope of each step, the tools used, and the treatment of history differ.
Map the source solution
Verify version and build, databases and companies, functional areas in use, custom objects, data, reports, integrations, infrastructure, and operational dates that the move must respect.
Compare the two routes
For technical migration and a new implementation, describe intermediate releases, decisions on customizations, data scope, integration work, risks, and the acceptance method.
Prepare the target environment and trial transfers
Configure target processes, prepare AL extensions, mappings, and integrations, and repeat data transfers in a test environment. Findings feed back into configuration and migration rules.
Validate operations and complete the cutover
Process owners complete acceptance scenarios, approve control totals, and confirm user readiness. The cutover plan defines final transfer, downtime, owners, archive, and support after go-live.
Frequently Asked Questions
When should we start?
Use the support end date for your version, the required intermediate releases, and time for repeated testing. Inventory can start before choosing a specific route. A customized solution with several integrations needs room for code conversion, trial migrations, and corrections identified during acceptance.
What is the difference between technical migration and a new implementation?
Technical migration retains database continuity and proceeds through supported intermediate releases; required C/AL customizations become AL extensions. A new implementation builds target processes and configuration again and moves agreed data through project-specific mappings and imports.
What happens to our customizations and custom tables?
They are inventoried and assessed against current standard functionality first. Required logic can become an AL extension, be replaced by an application, or be removed through a process change. Data in custom tables needs a corresponding target structure or explicit mapping and validation.
Does the complete data history migrate?
Technical migration can retain greater historical continuity where tables and customizations are compatible with the target solution. A new implementation selects data according to operational, accounting, and audit requirements. Data outside the live scope must remain securely archived and searchable.
What determines project scope, schedule, and cost?
The source version and build, number of intermediate steps, database size and quality, companies, customizations, integrations, history, test scenarios, and possible cutover windows. An estimate follows the inventory and a decision on which route will be designed in detail.
Related Topics
Process Analysis Before ERP Implementation
How to turn current processes, data, roles, and exceptions into target design and a delivery brief.
When Dynamics 365 Business Central Is a Good Fit
How to assess ERP fit across processes, data, integrations, customizations, and the operating model.
Dynamics 365 Business Central Implementation
From process and data analysis through migration and integrations to go-live and support.
Microsoft Cloud Solution Provider
You handle the move to Dynamics 365 and the licensing with one partner. We go through your situation and take care of both.
Plan the Move from Dynamics NAV.
In the initial conversation, we review the version, customizations, database, integrations, and expectations for the target operation. This defines the evidence needed to compare technical migration with a new implementation.
Discuss the Move from Dynamics NAV