Moving from Microsoft Dynamics NAV to Dynamics 365 Business Central is not simply a database copy or a version upgrade. The route depends on the NAV version, custom objects, third-party add-ons, integrations, localization requirements and whether the target is Business Central online or on-premises. A migration plan that ignores these dependencies can underestimate effort, extend downtime and carry avoidable technical debt into the new environment.
This guide explains the main migration decisions, the upgrade path considerations published by Microsoft, and the work an organization should scope before selecting an implementation partner. Microsoft updates supported paths over time, so treat the official upgrade documentation as the authority for the exact source and target versions in your project.
Can Dynamics NAV migrate directly to Business Central online?
Dynamics NAV versions earlier than Business Central version 14 cannot move directly to Business Central online. Microsoft’s current standard route requires an on-premises upgrade first. For NAV 2015–2018, the documented path to Business Central 2026 release wave 2 (version 29) is Business Central version 14, then version 25, then version 29, before cloud migration. NAV 2013 and 2013 R2 require an intermediate upgrade to NAV 2018 before version 14; NAV 2009 SP1 and 2009 R2 require earlier intermediate steps as well.
Microsoft also documents a reimplementation alternative after reaching Business Central version 14. That route moves essential data—such as master data, opening balances, selected posted history and setup—instead of carrying forward the full customized application. The precise route must be checked against the source version and target release when the project is scoped; Microsoft’s upgrade documentation changes as new releases arrive.
Do not use a generic migration diagram as the final technical plan. Confirm the current source version, cumulative update, SQL Server version, database compatibility level, installed localizations and target release against Microsoft’s supported upgrade paths and NAV-to-cloud migration guidance.
Full migration or reimplementation?
Two broad approaches may be considered after assessing the existing NAV environment:
Full migration
Full migration: This path is intended to bring forward the existing application and its data. Microsoft requires C/AL customizations that affect migrated tables to be converted into AL extensions and installed appropriately; the database must also be upgraded through the supported on-premises route before cloud migration. It suits organizations that need to retain a broader set of application data and custom functionality, provided the conversion effort is justified.
Reimplementation
Reimplementation: Microsoft’s Business Central 14 reimplementation tool is an alternative for organizations that do not need to upgrade and convert the full legacy application. It moves essential business data—such as master data, opening balances, a subset of posted historical entries and setup—so the organization can redesign processes without converting every C/AL customization. Confirm data scope, archive access and reporting requirements before choosing this route.
The choice is a business decision as much as a technical one. Retaining every historical record and customization can preserve continuity, but it can also increase conversion, testing and support costs. A clean start may simplify the application but requires clear decisions about archive access, reporting history and process redesign.
What happens to C/AL customizations?
Older Dynamics NAV environments often contain C/AL modifications to standard objects, partner-developed add-ons and customer-specific integrations. Business Central online uses the AL extension model. Microsoft states that customizations must be handled through extensions for the relevant cloud migration paths; data in tables affected by code customizations cannot simply be carried forward unchanged if those customizations have not been converted and installed appropriately.
Build a customization inventory before estimating the project. For every modification, record:
- The business process and users it supports.
- Whether it is still used and whether standard Business Central now covers the requirement.
- The source code, owner, documentation and dependencies.
- Whether it can be replaced by configuration, an AppSource extension, a per-tenant extension or a redesigned process.
- The conversion, regression testing and future maintenance effort.
A useful rule is to avoid converting a customization merely because it exists. Confirm its business value and test whether the standard product or a supported extension meets the requirement first.
Migration workstreams to plan
1. Assess the current environment
Document the NAV version, database size, company count, SQL Server environment, integrations, reports, scheduled jobs, modified objects, ISV solutions and country-specific functionality. Identify business-critical processes and any operational workarounds that have become embedded in the current system.
2. Define the target architecture
Decide whether the target is Business Central online or on-premises. Map the required Microsoft 365, Power Platform, reporting, ecommerce, warehouse, payroll, banking and industry applications. Identify which system owns customers, vendors, items, prices, dimensions and other master data. Confirm the required localization and extension availability for each operating country.
3. Prepare and cleanse data
Review duplicate and inactive records, item and vendor masters, dimensions, units of measure, posting groups, open transactions and historical data volumes. Define what will be migrated, archived or excluded. Agree reconciliation rules for trial balances, inventory quantities, open sales and purchase documents, fixed assets and other critical records.
4. Convert extensions and integrations
Plan the conversion of C/AL customizations to AL extensions where required. Review third-party add-ons for Business Central compatibility and replacement options. Rebuild integrations using supported APIs or integration services, and document data ownership, frequency, error handling, monitoring and support responsibility.
5. Test the complete business process
Testing should cover more than whether records appear in the new system. Run end-to-end scenarios across order-to-cash, procure-to-pay, inventory transfers, manufacturing, service, bank reconciliation, tax, financial close and reporting. Include role permissions, approvals, exception handling, integrations and month-end routines.
6. Rehearse cutover and post-go-live support
Perform at least one full migration rehearsal in a non-production environment. Measure elapsed time, identify failures, validate data and involve business owners in sign-off. The final cutover plan should define transaction freeze windows, backup and rollback criteria, data validation owners, user communication, support coverage and escalation paths.
What drives NAV-to-Business-Central migration cost?
There is no reliable single price for a NAV migration. Cost depends on the starting version, upgrade hops, database size, customization volume, number of companies, integrations, localizations, reporting requirements and the target deployment model. The implementation partner’s delivery approach and the amount of internal business time required also affect the total.
Ask for a work-breakdown estimate covering:
- Discovery, architecture and migration planning.
- Technical upgrades and database preparation.
- AL extension conversion or replacement.
- Data cleansing, migration and reconciliation.
- Integration and report redevelopment.
- Functional testing, user acceptance testing and training.
- Cutover, hypercare and ongoing support.
- Licensing, third-party apps, cloud services and internal project resources.
Compare the three-to-five-year total cost of ownership rather than only the implementation quote. A lower initial estimate can become more expensive if it excludes add-ons, integration maintenance, data remediation or post-launch support. For a broader cost framework, see the ERP implementation cost guide and ERP data migration checklist.
Questions to ask a Business Central migration partner
- Which NAV versions and upgrade paths have you delivered, and can you explain the technical route for our exact source version?
- How will you inventory and classify C/AL customizations and third-party add-ons?
- Which customizations should be retired, replaced or converted to AL extensions, and who approves those decisions?
- How will you reconcile financial, inventory and open-document data after each migration rehearsal?
- How will integrations, reports and country localizations be validated?
- What is included in the fixed scope, what is estimated separately, and how are change requests priced?
- What are the cutover, rollback, hypercare and support arrangements?
Conclusion
A successful Dynamics NAV to Business Central migration starts with a fact-based assessment of versions, customizations, data and operating requirements. Confirm Microsoft’s current supported path, decide what should be retained or redesigned, and require a rehearsed migration with business-led reconciliation. The objective is not just to move the old system; it is to reach a supportable Business Central environment with a clear cost and ownership model.
