techone --guide=nav-to-bc
Move from Dynamics NAV Around the Company's Target Processes
The company now works differently than when Dynamics NAV was introduced. We define the target processes and review customizations, data and integrations before choosing a migration route.
TL;DR
- The Starting Question
- We first need to understand how the company works today and how it should operate after the change. Only then can we decide what to retain, redesign or leave behind.
- Coordinated Workstreams
- Process analysis defines the needs of the target operation. The Dynamics NAV technical inventory identifies migration options, risks, dependencies and effort.
- The Resulting Decision
- The result can be a technical migration, a new implementation or a combination. Each customization, integration and data area receives its own target decision.
- 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 reason for change, operational areas in scope and process owners. On the technical side: exact version, companies, customizations, integrations, reports, data volume and history requirements.
Processes and the Target State Come Before Migration
A process analyst first reviews real work with management and operational users. The analysis captures roles, handoffs between teams, approvals, documents, exceptions and manual records outside Dynamics NAV. Process owners then define the target way of working.
A technical inventory of Dynamics NAV runs alongside this work: version, objects, custom logic, data, reports, integrations, infrastructure and operational constraints. A Dynamics consultant and technical architect compare that inventory with the target processes after the company's needs are clear.
Technical migration may be the right route. It is not the automatic objective. Every current function needs a reason, an owner and an acceptance method in the target operation.
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 age of Dynamics NAV does not determine the route by itself. The process view defines what the company needs to do differently. The technical view shows whether the required capabilities, data and connections can be migrated safely, replaced with standard functionality or redesigned.
Current and Target Processes
We first document real work today and the target state after the change. Their differences become the requirements for ERP, integrations, roles, data and user preparation.
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.
Technical Inventory Follows the Process Decisions
Before designing the move, we inventory custom objects, fields, tables, reports and connected systems. For each customization, we first establish its business purpose. We then decide whether Dynamics 365 Business Central standard functionality covers it, a suitable app exists, an AL extension is needed, or the process should change.
We use the same principle for data. Migration scope follows future use, legal and operational needs and source quality. 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 Decision and Transition Plan Are Created
Process and technical work proceed in coordination. Each workstream answers different questions and produces outputs that meet in the target design.
Document Current Operations
A process analyst maps work across teams, roles, documents, handoffs, approvals, exceptions, systems in use and current weaknesses.
Design the Target Way of Working
With process owners, we prepare target processes, rules, responsibilities, exceptions, information needs and change priorities.
Connect the Target State with the Dynamics NAV Inventory
A Dynamics consultant and technical architect assess standard functionality, customizations, data and integrations. Each area is retained, replaced, redesigned, archived or retired.
Prepare the Target Solution and Transition Plan
The output combines architecture, the migration catalog, integration flows, acceptance scenarios, trial transfers, ownership, stages, risks and an effort estimate.
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.
From Accounting Software to Dynamics 365 Business Central
How to decide what a new ERP should own and whether D365 BC is the right next step.
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.
Start with a Review of the Company and Its Current Dynamics NAV
We first need to understand what the target solution should change. We will then propose the scope of the process review and Dynamics NAV technical inventory.