Upgrading Microsoft Dynamics NAV 2017 to Dynamics 365 Business Central is no longer the same technical process described in older NAV upgrade guides. Business Central has moved to an extension-based, AL-oriented architecture, and the supported path depends on your current NAV version, customizations, extensions, database, and whether you are moving to Business Central on-premises or Business Central Online.
This updated guide explains the current 2026 upgrade path for NAV 2017 and the major technical and business considerations. It is intended as a planning guide, not a substitute for Microsoft’s version-specific upgrade documentation.
Can NAV 2017 Be Upgraded to Business Central in 2026?
Yes, but NAV 2017 cannot simply be upgraded directly to Business Central 2026 release wave 1 (version 28). Microsoft’s current supported path for NAV 2015–2018 to Business Central version 28 goes through Business Central Spring 2019 (version 14) and Business Central 2024 release wave 2 (version 25), before moving to version 28. The path also requires conversion of C/AL customizations to AL. citeturn0search6turn0search10
Current NAV 2017 to Business Central 2026 Upgrade Path
- Assess the existing NAV 2017 environment. Inventory custom objects, C/AL code, reports, integrations, third-party add-ons, data, localization and dependencies.
- Create a complete backup and test environment. Preserve the original NAV environment and perform the upgrade first in a controlled development or test environment.
- Move through the supported intermediate versions. For the 2026 version 28 path, NAV 2017 follows the supported route through Business Central version 14 and version 25 before version 28. citeturn0search6
- Convert customizations. Older C/AL customizations need to be converted and refactored into the AL/extension model required by current Business Central.
- Review third-party extensions. Confirm that each required extension has a compatible version or determine whether it needs to be replaced or rebuilt.
- Validate data and integrations. Review master data, open transactions, historical data, integrations, reporting and external dependencies.
- Test the upgraded solution. Run functional, integration, security, data and user-acceptance testing before production cutover.
- Plan production migration or cloud migration. If the target is Business Central Online, use Microsoft’s supported migration process rather than treating the move as a traditional database upgrade.
NAV 2017 to Business Central Online
Moving directly from NAV 2017 to Business Central Online is not a one-step cloud migration. Microsoft states that NAV versions before version 14 must first be upgraded to Business Central on-premises before moving to the cloud. For NAV 2015–2018, the supported route includes Business Central version 14 on-premises, a later supported Business Central on-premises version, and then Business Central Online. citeturn0search7
Microsoft’s migration guidance also requires organizations to address customizations and extensions before cloud migration. Custom functionality needs to fit the extension-based architecture, and data from tables containing code customizations cannot simply be carried forward as-is. citeturn0search8
What Happens to NAV 2017 Customizations?
This is often the largest part of an NAV modernization project. NAV 2017 solutions may contain C/AL customizations, modified standard objects, custom reports and integrations that do not map directly to modern Business Central.
A proper assessment should classify every customization as:
- Replace with standard Business Central functionality
- Replace with a Microsoft AppSource extension
- Rebuild as an AL extension
- Replace through an integration
- Retire because the business requirement no longer exists
Reducing unnecessary custom code before migration can lower upgrade complexity and future maintenance costs.
Important Data Migration Considerations
Before migration, clean and validate customer, vendor, item, financial, inventory, user, dimensions and other required data. Also document which historical transactions must remain available, which data can be archived, and which integrations depend on NAV database structures.
Do not assume that every historical customization or table can be moved unchanged. Modern Business Central uses a different application and extension architecture, so data and application design must be evaluated together.
Technical Upgrade vs. Business Central Online Migration
| Area | Modernization / On-Premises Upgrade | Move to Business Central Online |
|---|---|---|
| Application | Upgrade through supported versions | Move toward supported cloud architecture |
| Custom code | Convert/refactor to current architecture | Convert to supported extensions |
| Infrastructure | Customer or hosting environment | Microsoft SaaS platform |
| Data migration | Version-specific upgrade process | Cloud migration process plus supported upgrade path |
| Testing | Required at every major transition | Required before cloud cutover and for integrations |
Common NAV 2017 Upgrade Risks
- Underestimating the amount of custom C/AL code
- Assuming a direct upgrade path exists
- Using obsolete technical procedures from older NAV documentation
- Ignoring third-party extension compatibility
- Moving poor-quality data into the new environment
- Failing to test integrations and reports
- Trying to reproduce every historical customization instead of evaluating the business requirement
- Choosing a target version before completing the technical assessment
Should You Upgrade NAV 2017 or Move to Business Central Online?
The answer depends on your business, compliance, integrations, customization footprint and infrastructure strategy. If your organization wants a modern SaaS ERP with Microsoft-managed infrastructure and continuous updates, Business Central Online may be the preferred target. If specific infrastructure or operational requirements prevent a cloud deployment, a supported on-premises Business Central deployment may be more appropriate.
The decision should be made after an assessment of application customizations, data, integrations, regulatory requirements, total cost of ownership and user needs.
2026 Business Central Upgrade Planning Checklist
- Identify current NAV version and database architecture
- Inventory C/AL customizations and modified objects
- Inventory third-party solutions and integrations
- Map customizations to standard Business Central functionality
- Define the supported intermediate upgrade path
- Plan AL conversion and extension strategy
- Clean and validate data
- Build a test environment
- Run functional and integration testing
- Plan user training and change management
- Define cutover, rollback and support procedures
- Validate the final target version and Microsoft’s current upgrade documentation before production
Frequently Asked Questions
Can NAV 2017 be upgraded directly to Business Central 2026?
No. Microsoft’s current supported path to Business Central version 28 uses intermediate versions. NAV 2017 follows a route through Business Central version 14 and version 25 before version 28. citeturn0search6
Can NAV 2017 move directly to Business Central Online?
No. Microsoft requires older NAV versions to first move through supported Business Central on-premises versions before migrating to Business Central Online. citeturn0search7
Do NAV 2017 customizations need to be rewritten?
Many legacy C/AL customizations need to be converted or redesigned for the modern AL and extension architecture. The exact work depends on the customization and target version.
Is NAV 2017 still a good long-term ERP platform?
NAV 2017 is a legacy product generation. Organizations still running it should evaluate modernization because current Business Central provides a modern application architecture, cloud options, regular updates and ongoing investment in AI and business capabilities.
Final Takeaway
A NAV 2017 upgrade in 2026 should be treated as an ERP modernization project, not a simple software-version change. The safest approach is to follow Microsoft’s supported upgrade path, rationalize customizations, modernize integrations, validate data and test the target environment thoroughly.
Microsoft changes supported upgrade paths and product versions over time. Always verify the current version-specific upgrade documentation before executing a production migration.

