NAV to Business Central Migration Scenarios: Online, On-Premises & Customizations

Organizations moving from Dynamics NAV to Business Central can follow different migration paths depending on the NAV version, deployment model, customizations, extensions and target environment. The correct approach should be based on the supported Microsoft path rather than an old one-size-fits-all upgrade checklist.

Scenario 1: NAV 2015–2018 to Business Central 2026

For NAV 2015 through NAV 2018, Microsoft’s current path to Business Central 2026 release wave 1 (version 28) uses Business Central Spring 2019 (version 14), then Business Central 2024 release wave 2 (version 25), and then version 28. C/AL customizations must be converted to AL. citeturn0search6turn0search10

Scenario 2: NAV to Business Central Online

Older NAV versions cannot simply move directly to the SaaS service. Microsoft documents intermediate on-premises upgrade requirements before cloud migration. NAV 2015–2018, for example, follows a route through Business Central version 14 on-premises and later supported versions before Business Central Online. citeturn0search7

Scenario 3: Heavy C/AL Customization

Legacy customizations are often the most difficult part of modernization. Each customization should be assessed and classified as standard functionality, an extension, an integration, a redesigned process or something that can be retired.

Scenario 4: Third-Party Extensions

Inventory every extension and confirm whether a current compatible version exists. If an extension has been discontinued, identify a replacement before the production migration.

Scenario 5: Business Central Already on a Supported Version

Organizations already on modern Business Central versions may have a much shorter upgrade route. Microsoft publishes version-specific supported paths and compatibility requirements, so the source version should be confirmed before planning the project. citeturn0search10

Scenario 6: Multiple Countries or Localizations

Global deployments require additional attention to local functionality, tax, regulatory requirements, currencies, dimensions, reporting and integrations. Plan country rollout and validation separately where appropriate.

Scenario 7: Poor Data Quality

A migration is an opportunity to clean master data, duplicates, inactive records and obsolete history. Define data ownership and reconciliation rules before migration testing begins.

Scenario 8: Complex Integrations

Document all systems that exchange information with NAV, including CRM, e-commerce, banking, warehouse, payroll, tax and reporting platforms. Do not assume an old integration will work with the target architecture.

How to Choose the Right Scenario

1. Identify the exact source version.
2. Document customizations and extensions.
3. Confirm the desired target deployment.
4. Review data and integrations.
5. Check Microsoft’s supported upgrade path.
6. Build a proof-of-concept migration.
7. Complete testing before production cutover.

Key Risks

• Assuming a direct upgrade exists
• Carrying obsolete customizations forward
• Ignoring extension compatibility
• Skipping data cleansing
• Underestimating integration testing
• Using technical instructions written for obsolete versions

Final Takeaway

NAV modernization should be planned around the starting version and target architecture. Microsoft’s current documentation shows that older NAV versions may require intermediate Business Central versions, while cloud migration adds additional application and extension requirements. citeturn0search6turn0search7

Verify the supported path for your exact NAV/Business Central version before executing an upgrade.