NAV to Business Central Migration Checklist

Why is moving from NAV to Business Central a migration and not an upgrade?

Because the way the system is extended changes underneath you. Microsoft's documented path takes Dynamics NAV customers to Business Central, first on-premises and then online, so the data has a defined route across. The customisations do not travel the same way. Business Central extensions are written in AL, using the AL Language extension for Visual Studio Code, and they sit beside the standard application. A NAV estate modified inside the application over many upgrades has to be taken apart: each change becomes standard functionality, an AL extension, an app or a deletion.

Where the system runs changes too. Business Central can be deployed online, with data stored in the Microsoft cloud, or on-premises. Moving online means anything that relied on reaching into your own servers, such as direct database reads, file shares or local services, needs a new design.

The clock is real. Dynamics NAV 2018 mainstream support ended on 10 January 2023 and extended support ends on 11 January 2028. For older NAV versions, check the Microsoft Lifecycle page for your exact version.

Who is this NAV to Business Central checklist for?

It is written for the people who have to sign the plan, not only for the people who build it.

• Finance directors and IT leads at companies running Dynamics NAV 2018 or an older version, who need a plan before support runs out.
• Companies already on Business Central on-premises that want to move to Business Central online.
• Microsoft partners with NAV clients who need more AL capacity: Solzet works white-label inside your delivery process.
• Companies in Armenia moving from NAV, who also need the Business Central Armenian localization.
• On Dynamics GP rather than NAV? Read what to do before Dynamics GP support ends.
• Moving from 1C? The 1C to Business Central migration guide covers that route.
• Already live on Business Central and unhappy with it? Solzet can audit your existing project and give you a stabilisation plan.

What is on the NAV to Business Central migration checklist?

Seven phases, in order. Each one produces something the next one needs, which is why skipping ahead tends to come back as rework. Print it, assign an owner to every line, and use it as the agenda for the first steering meeting.

1. 1

   Assess the NAV estate

   Record the NAV version, companies, modules in use, customisations, add-ons, integrations, reports, users and data volumes, and agree the target: Business Central online or on-premises.

   • NAV version and update level, the companies in the database, and which of them are still trading.
   • The modules and features used every day, by department, and the ones nobody has opened for a long time.
   • Every customisation: what it changes, what it is for, who asked for it and whether anyone still needs it.
   • Third-party add-ons, their vendors, and whether each vendor offers a Business Central version.
   • Every integration: which system reads from or writes to NAV, how, how often and who owns it.
   • Reports, documents and Excel exports the business depends on, including the ones finance runs at month end.
   • Database size, how much history there is, and the data quality problems finance already knows about.
   • Servers, SQL Server and hosting contracts, and the dates their own support ends.
2. 2

   Decide every customisation

   Classify each customisation as standard functionality, an AL extension, a Microsoft Marketplace (AppSource) app or retirement, and turn the result into an extension backlog with an owner per item.

   • Check first whether standard Business Central now covers the requirement with configuration.
   • Look for an existing app on Microsoft Marketplace (AppSource) before rebuilding generic functionality.
   • Rebuild what is genuinely specific to your business as AL extensions that sit beside the standard application.
   • Retire the rest, with the business owner confirming each retirement in writing.
   • Write acceptance criteria for every extension before development starts, so testing has something to test against.
3. 3

   Plan the data upgrade path

   Follow the documented route from Dynamics NAV to Business Central on-premises and then the cloud migration tool to Business Central online, decide how much history moves, and clean the data first.

   • Confirm the upgrade path for your exact NAV version on Microsoft Learn before planning anything else.
   • If you already run Business Central on-premises version 15 to 24, plan the upgrade to version 25 first; version 25 or later migrates directly.
   • Decide the history: everything, recent periods plus opening balances, or master data and open items only, with NAV kept read only for the rest.
   • Clean master data before the first trial: duplicate customers and vendors, blocked records, unused items and inconsistent coding.
   • Close and reconcile periods in NAV, so the migrated balances have a signed-off starting point.
   • Plan more than one trial migration, and time each one.
4. 4

   Redesign the integrations

   Replace direct database access, file drops and on-premises services with Business Central APIs and supported connectors, and decide how the CRM connects.

   • List each integration with its direction, frequency, volume, owner and what breaks if it stops.
   • Redesign anything that reads or writes the NAV database directly around Business Central APIs.
   • For Dynamics 365 Sales, plan the Dataverse connection; for Power Apps and Power Automate, consider Business Central virtual tables in Dataverse.
   • Re-point and retest banking, EDI, e-commerce, payroll and warehouse feeds against the new endpoints.
   • Agree error handling, retries and monitoring for every integration before go-live, not after the first failure.
5. 5

   Test with migrated data

   Test end to end on a trial migration: reconciliation, posting, documents, extensions, integrations and permissions, finishing with user acceptance by key users.

   • Reconcile the trial balance, customer and vendor open items, and inventory quantities and values against NAV.
   • Run whole processes, not screens: order to cash, purchase to pay, stock movements and a month-end close.
   • Test every extension against its acceptance criteria.
   • Check every document a customer, supplier or authority receives: invoices, statements, remittances and statutory reports.
   • Run integrations with realistic volumes and deliberate failures.
   • Test permissions role by role, including what people must not be able to see.
   • Close with user acceptance testing by named key users, signed off in writing.
6. 6

   Rehearse and run the cutover

   Rehearse the cutover, agree go and no-go criteria, freeze NAV, run the final migration, reconcile, sign off and keep NAV read only as the fallback and the archive.

   • Rehearse the full cutover at least once on a copy of production, with timings recorded.
   • Pick a period boundary for go-live, so opening balances and the first close are clean.
   • Agree go and no-go criteria in advance, and who makes the call.
   • Freeze NAV, run the final migration, reconcile and get finance sign-off before users start posting.
   • Keep NAV available read only, for history, audit questions and as the fallback.
7. 7

   Train users and hand over

   Train by role on the processes that changed, appoint super-users, support the first period-end close and hand over documentation and support.

   • Train by role, on real tasks in a test environment with migrated data, not on generic demo data.
   • Spend the training time on what changed, not on what users already know from NAV.
   • Appoint super-users in each department as the first line of help.
   • Support the first period-end close closely, because that is when missing steps surface.
   • Hand over documentation for every extension and integration, and agree who supports what from the first day.

How should each NAV customisation be handled in Business Central?

One decision per customisation, made with the person who owns the process, and written down. The goal is the smallest set of extensions that keeps what genuinely differentiates the business, because every extension you keep is code you test on every Business Central update for as long as you run it.

The extension backlog that comes out of this exercise is the real scope of the project. Development of the AL extensions themselves is described on our Business Central AL development page.

Which data upgrade path applies to your NAV version?

Microsoft's route for Dynamics NAV is to upgrade to Business Central on-premises first and then switch to Business Central online with the cloud migration tool. Business Central on-premises version 25 or later migrates directly; versions 15 to 24 upgrade to version 25 first. The intermediate steps from older NAV versions are documented on Microsoft Learn, and the assessment should confirm them for your exact version before any plan is approved.

The other decision is how much history to carry. A full upgrade brings everything. A fresh start implements Business Central cleanly and loads master data, open items and opening balances, with NAV kept read only for the past. The fresh start suits estates whose data carries years of workarounds; the full upgrade suits estates whose data is sound and whose history is needed day to day.

What happens to NAV integrations when you move to Business Central online?

They are redesigned, not copied. Business Central online runs in the Microsoft cloud, so integrations that read or wrote the NAV database directly, dropped files on a server share or called services on your local network need a new route. Business Central APIs are the default integration point, and middleware that can be re-pointed takes far less work to move than point-to-point code that has to be rewritten.

If you run Dynamics 365 Sales, Business Central connects to it through the Dataverse connection, with one-way or two-way synchronization. The Business Central Virtual Table app exposes Business Central data in Dataverse as virtual tables without copying it, which suits Power Apps and Power Automate that need to read ERP data. The CRM side of that design is covered on our Dynamics 365 Customer Engagement consulting page. If your CRM is a custom-built CRM rather than Dynamics 365, the same Business Central APIs serve it.

• Banking and payment files: confirm formats and the route the files take once there is no local server.
• EDI and e-commerce: re-point to Business Central APIs and retest with real order volumes.
• Payroll and HR: decide the journal format and posting frequency.
• Warehouse and shipping systems: agree who owns stock quantities and how often they sync.
• Reporting and BI: rebuild reports that queried the NAV database directly against APIs or exported data.

How do you test a NAV to Business Central migration properly?

Against a trial migration of real data, with finance deciding when the numbers agree. Testing screens on demo data proves very little; testing whole processes on migrated data proves the thing you are about to bet the month-end close on.

How should the cutover from NAV be planned?

As a rehearsed routine rather than a heroic weekend. By cutover day the migration should have run often enough that the final run is uneventful.

• Rehearse the full cutover on a copy of production, record how long each step takes and fix whatever surprised you.
• Go live at a period boundary, ideally the start of a month or a quarter, so opening balances and the first close are clean.
• Write the go and no-go criteria in advance, and name the person who makes the call.
• Communicate the freeze: when NAV stops taking postings, and what users do in the gap.
• Run the final migration, reconcile against the frozen NAV figures and get finance sign-off before anyone posts.
• Keep NAV available read only for history, audit questions and as the fallback.
• Staff the first weeks with people who can fix things the same day.

What training do NAV users need for Business Central?

Less than they fear and more than a one-hour demo. Users who know NAV well already understand the accounting. What they need is the changed processes, the new screens for their own tasks and the confidence that they can find things again.

Train by role in a test environment loaded with migrated data, so each person practises on their own customers, items and accounts. Appoint super-users in each department before go-live and give them extra time with the consultants, because they will answer most of the questions in the first month. Then support the first period-end close closely: that is where a missing step or a misunderstood report shows up.

Is Business Central or Finance and Operations the right destination for a NAV company?

For most companies on Dynamics NAV, Business Central is the natural destination: it is Microsoft's ERP for small and mid-sized organizations, covering finance, sales, purchasing, inventory, projects, manufacturing, warehouse and service management in one system. Some NAV companies have grown into a shape that fits Finance and Operations better, usually through several legal entities, multi-country finance or deep supply chain and production needs. The assessment is the right moment to check, before the extension backlog is designed for one product.

What drives the effort of a NAV to Business Central migration?

The number of customisations you keep, far more than the size of the database. A NAV estate with a short extension backlog and clean data is a contained project; one with heavy modifications, several integrations and doubtful data is a programme. The assessment exists to tell you which one you have before anyone quotes.

• Customisations kept: each one is designed, built, tested and maintained as an AL extension.
• Third-party add-ons: whether each vendor has a Business Central app, or an alternative has to be found.
• Integrations: how many touch NAV directly, and how many of them nobody has documented.
• Data: how much history moves, and how much cleaning it needs first.
• The NAV version: how many upgrade steps sit between it and Business Central on-premises.
• Companies and localization: how many companies move, and which local requirements apply.
• Availability of key users for decisions, testing and sign-off.

How does Solzet run a NAV to Business Central migration?

Solzet implements Dynamics 365 Business Central online, builds AL extensions and integrations, and migrates companies from Dynamics NAV, Dynamics GP, 1C and other ERPs. A NAV project starts with a fixed-scope assessment that produces phases one and two of this checklist for your estate: the inventory, the decision for every customisation, the upgrade path for your version and a recommended plan. The written output stands on its own.

Delivery then follows the remaining phases, with a decision point at the end of each: the AL extensions, the data upgrade and trial migrations, the integrations, testing, cutover and training. The same team designs the CRM side when you run Dynamics 365 Customer Engagement, so customers, orders and invoices mean the same thing in both systems. The service itself is described on migration to Business Central, the wider Business Central practice on Dynamics 365 Business Central, and the rest of our guides are in the guides library.