techone --guide=nav-to-bc
From Dynamics NAV (Navision) to Dynamics 365 Business Central
Moving from Dynamics NAV to Dynamics 365 Business Central means a new system on a new platform. You decide which customizations to keep and which to rebuild.
TL;DR
- Who this guide is for
- Companies on older Microsoft Dynamics NAV (Navision) deciding whether to stay put or move to Dynamics 365 Business Central.
- What it covers
- When it is time to move, why a heavily customized Dynamics NAV calls for a new system, what data actually migrates, and where AI speeds up the work.
- End of support
- Microsoft no longer develops Dynamics NAV 2009 R2, 2013, 2015 and now 2016. Version 2018 stays in security support until January 2028. All belong on the migration plan.
- Recommended path
- For an old, heavily customized Dynamics NAV, rebuild on a clean D365 BC rather than a mechanical upgrade, carrying over only the data and processes that make sense.
- How to start
- A current state analysis: scope of customizations, data volume, integrations. It tells you what to carry over, what to rewrite and what to simplify.
When It Is Time to Move
The deadline depends on your version. If you are on Dynamics NAV 2018, you have time. On older versions Microsoft has closed development, so the move belongs on the plan. Here is the picture.
Dynamics NAV 2009 R2, 2013 and 2015
All long out of support, no longer developed by Microsoft. They belong on the plan to move to D365 BC.
Dynamics NAV 2016
Extended support ended in April 2026, so Microsoft no longer develops the version. Dynamics NAV has no paid extended security option, which means you cannot buy yourself another delay.
Dynamics NAV 2018
Still in security support until January 2028. If you run 2018, you have time and do not need to rush. Mainstream support has ended, though, so plan the move rather than leave it to the last minute.
What end of support means
The system keeps running, but Microsoft puts no new development into it. So you miss the modern capabilities that go into D365 BC: cloud, integrations, AI and continuous updates.
How the move works
For an old and heavily customized Dynamics NAV, just porting the existing functions into a new version is rarely enough. Your company has changed over the years: processes were added, others shifted, and customizations and workarounds piled up that often no longer match how you operate today. The move is the moment to consolidate those processes and shape the system around how you work now, not around how things were years ago. The realistic path runs through a clean Dynamics 365 Business Central: you start fresh and decide on purpose what to keep, what to rebuild and what to simplify.
What to carry over and what to rewrite is not guesswork. It comes out of a current state analysis. For what such an analysis looks like and what you get from it, see our guide to process analysis before an ERP implementation.
Current state analysis
What runs as standard in Dynamics NAV and what is a customization. Data volume and quality, the list of integrations and connected systems. Without this, the move is planned blind.
A decision on every customization
For each customization a decision is made: standard D365 BC covers it, it moves to an AL extension, or the process is set up differently. This is where most of the saving happens.
Setup and development on a clean D365 BC
A fresh environment is stood up, standard processes are configured, and the customizations worth keeping are written as AL extensions. A new system without legacy baggage.
Cloud migration and go-live
Data transfer into the cloud edition, acceptance testing with your people, and support during go-live. The old system stays as a fallback.
What Actually Migrates
The migration moves tables that exist in both systems. Master data almost always comes across: customers, vendors, items. Alongside it go selected transactional data, opening balances and the tables that hold the base setup. What happens to long document history is not a fixed rule. It is a project decision, and we make it together based on how much history you really need in the live system and how much is fine to archive.
Mind the customizations. Data from customized tables does not come over on its own. Custom fields and custom tables have to be rebuilt in the new system as AL extensions, and the mapping between the old and new model has to be defined by hand. That part tends to be the most labor-intensive. And that is exactly where we speed the work up, as the next section describes.
Master data
Customers, vendors, items. The backbone of the records, and what comes across almost every time.
Selected transactions and balances
Open documents, opening account balances and ledgers. The scope is chosen by what you need live from day one.
Setup tables
Code lists, chart of accounts, module settings. Some of it carries over, some gets straightened back to a clean standard while the new system is built.
Customizations and custom fields
These do not come over automatically. Code is rewritten from C/AL to AL extensions, custom fields are mapped by hand. This is work, not a flipped switch.
Document history
There is no automatic rule for long history. We decide it together: part into the live system, the rest into an archive you can still reach.
How AI Helps Us
The hard part of a migration is the data: transforming it, consolidating it, cleaning it up, and checking that everything lines up after the move. We build tools tailored to your data for that, and AI speeds up how fast we build them.
Microsoft provides the transfer layer; the transformation, the checks and the conversion of customizations we build on top. Three places where AI saves us the most time:
Mapping and transformation
Tools that remap data from the old model and convert it into the structure of the new system.
Consolidation and cleanup
Merging duplicates, fixing inconsistencies and filling gaps so the data enters the new system clean.
Validation and reconciliation
Checking that document counts and balances after the move match the source system, not just a sample.
The faster we build those tools, the sooner you have a new system without the legacy baggage.
Continuity and Proof
Moving off an old system never stands alone. It almost always comes with integrations to other systems and decisions about how to run the solution afterward. For how implementation and system integration follow the analysis, see our ERP integration service. For why we choose D365 BC as the target platform, see our guide to Dynamics 365 Business Central.
From practice: for IBG we connected Dynamics CRM, Dynamics NAV and SharePoint into a single data flow, so we know the Dynamics NAV environment and its connections well. For Tesil Fibres we handled the move from Oracle E-Business Suite to Dynamics 365 Finance, including data migration and Czech localization. Same Dynamics family, same kind of task: getting a company off an aging system onto a current platform without losing data. For the step before the migration itself, see our guide to process analysis before an ERP implementation.
Frequently Asked Questions
Is it worth starting now, or waiting?
If you are considering the move, starting sooner pays off. On D365 BC you gain cloud, integrations, AI and continuous updates that the old Dynamics NAV versions will not get. The earlier you start with the analysis, the more room and options you have: you learn what the move involves and what carries over before committing to anything. The first step is a no-obligation call about your operations.
What is the difference between a new system and an upgrade?
An upgrade is mostly a technical move: the same functions, baggage and all, carried into a new version. But your company has changed over the years, and the old system often no longer reflects how you actually work today. A new system is the chance to put that right: review the processes, consolidate them, and shape the system around how you run now, not how things were years ago. It takes more work up front, but the result fits the reality of the business.
What happens to our customizations?
Customizations do not migrate on their own. Logic written in C/AL is rewritten as AL extensions, and custom fields are mapped to the new model by hand. For each customization we first judge whether standard D365 BC covers it, whether you genuinely still need it, or whether the process can be set up differently. What stays, we convert. This part of the project is the most labor-intensive, and we use AI to help with it.
Does the complete data history migrate?
Master data (customers, vendors, items) does. Alongside it come selected transactional data, opening balances and setup. What happens to long document history is not a fixed rule. We decide it together based on how much history you need in the live system and how much is fine to keep in an archive you can reach. The goal is a clean start, not lost data.
How long does the move take and how much does it cost?
It depends on the scope of customizations, the data volume and the number of integrations. That varies widely from company to company, so a flat number would be misleading. We give you a realistic frame after the initial analysis, once we know what migrates and what needs rewriting. No pressure and no blind estimates.
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.
Running on old Dynamics NAV?
We will walk through the state of your installation and tell you what the move to D365 BC would involve and in what order.
Book a consultation