Dynamics NAV to Business Central Migration: A Practical Checklist

Many US companies still run their finance, inventory and operations on Dynamics NAV. It often works fine day to day, which is exactly why the move keeps getting postponed. But NAV is a product Microsoft has replaced, and each year on it adds risk and makes the eventual migration harder.

This guide explains why companies move to Business Central, the main migration paths, and a phased checklist you can use to plan the project. It is written for owners, finance leaders and IT managers who want to understand the work before they talk to a partner.

Why companies move from NAV to Business Central

Business Central is Microsoft's successor to NAV. It shares NAV's roots, so core concepts like the general ledger, item ledger entries, posting groups and dimensions will feel familiar. What changes is how the system is delivered, extended and updated.

Support lifecycle

Every NAV release has a fixed Microsoft support lifecycle. Most NAV versions are already past the end of extended support, which means no more security updates, bug fixes or tax and regulatory updates from Microsoft. The newest NAV releases are approaching the same point. Check Microsoft's product lifecycle pages for the exact dates that apply to your version.

Running unsupported software is not only an IT concern. It can affect cyber insurance questionnaires, audit findings and your ability to run on current versions of Windows Server and SQL Server.

Cloud access and updates

Business Central online is a software as a service product hosted by Microsoft. Users sign in through a browser or mobile app, and there are no servers for you to patch. Microsoft ships regular updates, including major releases on a set schedule, so you stay current instead of facing a large upgrade every few years.

An on-premises version of Business Central also exists for companies with specific hosting requirements, though most new implementations choose the cloud.

Microsoft 365 integration

Business Central connects closely with Microsoft 365. Examples include working with Business Central data from Outlook, editing lists in Excel, sharing records in Teams and reporting in Power BI. For companies already on Microsoft 365, this often removes manual exports and copy and paste work.

Licensing model

Business Central online is licensed per user per month, with different license types for full users and lighter users. Licensing and pricing change over time, so confirm current terms on Microsoft's pricing page or with your partner rather than relying on older quotes.

The main migration paths

There is no single way to move from NAV to Dynamics 365 Business Central. The right path depends mostly on your NAV version, how heavily it is customized and how much history you need.

Technical upgrade plus cloud migration. Microsoft provides cloud migration tooling that moves data from supported on-premises versions into Business Central online. Older NAV versions usually need one or more upgrade steps first to reach a supported starting point, and custom code has to be converted along the way. This path keeps your existing data structure and history, but the effort grows with each version step and each customization.

Re-implementation. You set up Business Central fresh, using standard features where possible, and import selected data such as master records, open balances and a defined period of history. This path takes more design work up front but avoids carrying old workarounds forward. Many companies on very old or heavily modified NAV versions choose it.

Hybrid approaches. Some companies re-implement but use migration tools or scripts to bring over specific data sets. Others keep a read-only copy of NAV or an archive database for older history.

Neither path is universally better. Check Microsoft's current documentation for which versions the migration tools support, and ask any partner to explain why they recommend one path for your specific setup.

Phase 1: Assess your current NAV environment

A good assessment prevents most surprises later. Gather the facts before you commit to a path or a budget.

• Confirm your exact NAV version and cumulative update level
• List every customization: modified objects, custom tables, pages, reports and code units
• Note who wrote each customization and whether documentation exists
• Identify third party add-ons and check whether the vendor offers a Business Central version
• Map all integrations: e-commerce, EDI, payroll, banking, shipping, CRM, warehouse scanners
• Measure data volume: database size, number of companies, years of posted entries
• Document key reports and who uses them
• Interview users about pain points and workarounds they rely on

Expect to find customizations that nobody uses anymore. Flag them now so you do not pay to rebuild them.

Phase 2: Plan scope, history and cutover

With the assessment done, decide what the new system must do on day one and what can follow later.

• Choose the migration path and document the reasons
• Define scope: which companies, modules and processes are in phase one
• Decide what history to bring: full detail, summarized balances or open items only
• Decide where older history will live (archive database, read-only NAV, reporting tool)
• Pick a cutover date, ideally at a month, quarter or fiscal year end
• Review your chart of accounts and dimensions for cleanup opportunities
• Assign an internal project owner and process owners for finance, sales, purchasing and inventory
• Agree on budget, timeline and decision rules for scope changes

The history decision has a large effect on cost and risk. Bringing every posted entry from the last fifteen years is rarely necessary, and your accountant or auditor can help you decide what must be kept and where.

Phase 3: Rebuild or replace customizations

This is where NAV and Business Central differ most. In NAV, developers often changed standard objects directly in C/AL. In Business Central online, the base application cannot be modified. Customizations are built as AL extensions that add to standard behavior through events and extension objects.

For each customization, choose one of three options: rebuild it as an extension, replace it with a standard feature, or replace it with an app from Microsoft AppSource. Business Central has added many features over the years that once required custom code in NAV.

• Classify every customization as rebuild, replace with standard, replace with app, or retire
• Confirm AppSource apps are actively maintained and supported in your region
• Write a short specification for each extension before development starts
• Keep extension code in version control with a clear owner

Phase 4: Clean, migrate and reconcile data

Data quality problems in NAV do not disappear in Business Central. They just move. Treat data migration as its own workstream with its own owner.

• Remove duplicate and inactive customers, vendors and items
• Standardize addresses, payment terms, units of measure and posting groups
• Close or clean up old open entries that should not carry forward
• Build migration mappings from NAV fields to Business Central fields
• Run at least two trial migrations in a sandbox environment
• Reconcile trial balance, open receivables, open payables and inventory value against NAV
• Have finance sign off on each reconciliation in writing
• Time the final migration run so you know how long cutover will take

Reconciliation is the step most often rushed. If the numbers do not tie in a trial run, they will not tie at go-live either.

Phase 5: Test, train and go live

Testing and user acceptance testing

Testing should cover full business processes, not just individual screens. Write scripts that follow a sales order from entry to cash receipt, a purchase from requisition to payment, and a month-end close.

• Test each extension on its own and with standard processes
• Test every integration with realistic data volumes
• Run user acceptance testing with the people who do the work daily
• Test permissions and user roles
• Log, prioritize and retest every issue before sign-off

Training

Business Central looks and works differently from the NAV classic or Windows client. Users need hands-on practice, not just a demo.

• Train by role, using your own data in a sandbox
• Create short process guides for common tasks
• Identify a power user in each department

Go-live and hypercare

• Confirm a go or no-go decision with clear criteria
• Freeze NAV transactions and run the final migration
• Reconcile opening balances before users start posting
• Plan two to six weeks of hypercare with quick access to consultants
• Review open issues daily during the first weeks, then weekly
• Schedule the first month-end close with extra support

Common pitfalls to avoid

• Rebuilding every customization. Many NAV modifications existed because older versions lacked features. Review each one against current standard functionality first.
• Bringing too much history. Full history migration adds cost, time and reconciliation work, often for data nobody opens.
• Underestimating integrations. File drops and direct database connections usually need to be redesigned for the cloud.
• Skipping trial migrations. One test run is not enough to find mapping errors and timing issues.
• Thin user testing. If UAT is done by consultants instead of your staff, process gaps surface after go-live.
• Ignoring the update cadence. Business Central updates regularly, so extensions need to be maintained and tested against new releases.
• No internal owner. A partner can run the project, but decisions on scope and process must come from your team.

Next steps

Start with an honest assessment of your NAV version, customizations and integrations. That single exercise usually makes the right migration path clear and gives you a realistic basis for budgeting.

If you want a second opinion, an experienced partner can review your environment and walk you through the options. Invictus Hub offers NAV to Business Central migration services, and you can contact us to talk through your situation with no commitment.