Version and strategy guide
Dynamics NAV 2009–2018 to Business Central Migration Paths
Compare supported paths from Dynamics NAV 2009, 2013, 2015, 2016, 2017, and 2018 to Business Central, including full migration and reimplementation.
What to take from this guide
- Older NAV releases normally require controlled intermediate upgrades; the destination is not reached in one jump.
- Business Central version 14 is an upgrade bridge for C/AL solutions, not a new production destination.
- Full migration and reimplementation preserve different amounts of application and data continuity.
- The live compatibility matrix and a representative test upgrade—not the version name alone—determine feasibility.
Step zero
Identify the exact NAV starting point
A product label such as “NAV 2018” is not enough to approve an upgrade path. Establish the installed build, cumulative update, localisation, database architecture, code state, and third-party dependencies before choosing intermediate versions or a target.
- Product name, major version, build number, cumulative update, and executable version
- Australian or other localisation plus every company and tenant in scope
- SQL Server version, compatibility level, database size, collation, and topology
- Modified-object list, object deltas, source availability, and development licence position
- C/AL, AL, .NET, Automation, control add-in, client-side, and file-system dependencies
- Installed ISV products, add-ons, licences, versions, vendors, and supported successors
- Web services, APIs, files, EDI, ecommerce, bank, warehouse, reporting, and identity integrations
- Data history, attachments, audit or retention needs, and required legacy access
Version map
Microsoft’s documented routes from NAV to Business Central online
The table below summarises Microsoft's current high-level guidance as reviewed on 2 August 2026. It is not a substitute for the live compatibility matrix: supported target releases and compatible cumulative updates change over time.
Business Central version 14 was the last version that supported the C/AL development environment. Microsoft's upgrade guidance treats it as a bridge for older NAV solutions, not as a new production destination. The later target and intermediate cumulative updates must be selected from the current compatibility matrix.
A supported technical route does not by itself prove that every customisation, third-party product, localisation, report, integration, or business process will work. Those items need their own retain, replace, redesign, or retire decision.
| Starting release | Documented high-level route | Planning consequence |
|---|---|---|
| NAV 2015, 2016, 2017, or 2018 | Upgrade to Business Central on-premises version 14, then a currently supported newer on-premises release, then migrate to Business Central online. | Version 14 is an intermediate upgrade stage. Custom application code and data upgrade work still require assessment. |
| NAV 2013 or 2013 R2 | Upgrade to NAV 2018, then Business Central on-premises version 14, then a currently supported newer on-premises release, then online. | Add an NAV 2018 transition and validate every compatible build, localisation, app, and database prerequisite. |
| NAV 2009 SP1 or NAV 2009 R2 | Upgrade through NAV 2013 or NAV 2015, then NAV 2018, Business Central on-premises version 14, a currently supported newer on-premises release, and finally online. | Multiple controlled intermediate stages increase the need for repeatable scripts, backups, validation, and access to correct product media. |
Approach decision
Full migration and reimplementation solve different problems
Microsoft's current NAV migration guidance describes a full migration and a Business Central version 14 reimplementation path. The right choice depends on what must be preserved, what can be redesigned, and how legacy records will remain accessible.
| Decision area | Full migration | Reimplementation |
|---|---|---|
| Primary aim | Carry forward the agreed application, extension, and data continuity through supported upgrades and cloud migration. | Configure a new target and migrate an agreed set of essential business data rather than the whole legacy application and history. |
| Customisations | Required C/AL customisations must be converted or redesigned as AL extensions or replaced with supported apps or standard capability. | Legacy customisations are not automatically brought forward; required outcomes are re-evaluated and implemented separately where approved. |
| Data | Designed to preserve the agreed data through the supported upgrade and replication route, subject to custom table and extension requirements. | Focuses on supported essential setup, master, balance, and selected transactional data; exact tool scope must be checked in current documentation. |
| History and legacy access | Potentially greater continuity, but scope and successful upgrade still require validation and reconciliation. | Excluded history needs an archive, reporting, enquiry, retention, security, and retirement plan. |
| Main risk | Carrying unnecessary legacy complexity or underestimating intermediate upgrades and extension conversion. | Underestimating process redesign, data selection, opening positions, historical access, and user change. |
Decision framework
Choose a path from business evidence, not version alone
The starting release determines technical prerequisites, but it does not decide the project strategy. Use the following questions to expose the real trade-offs.
What must remain queryable?
Separate data needed for day-to-day processing from history needed for service, audit, tax, traceability, or analytics. Define how each category will be accessed after cutover.
- Open documents and operational balances
- Posted transactions and item traceability
- Attachments, document images, and audit evidence
- Legacy archive access, security, and retention
Which custom behaviour is still valuable?
Do not convert code merely because it exists. Trace each modification to a current process, control, statutory need, or competitive capability and compare it with standard Business Central and supported apps.
- Use evidence of current use and business ownership.
- Remove duplicate, obsolete, and workaround logic.
- Define outcomes before selecting an AL design.
What is the safe operating transition?
Consider whether all companies and capabilities can move together, how long the cutover window can be, and which external systems must change at the same time.
- Month-end, stocktake, and peak trading constraints
- Integration sequencing and temporary interfaces
- Reconciliation, rollback, and support coverage
What can the organisation absorb?
A project needs timely process decisions, data ownership, UAT, training, and sign-off from the customer. A technically sound plan can still fail if those people are unavailable.
- Named workstream owners and delegates
- Realistic subject-matter expert capacity
- Decision deadlines and escalation paths
Common constraint
Custom tables and C/AL code affect what data can move
For Business Central online, custom application behaviour must be handled through extensions. Microsoft's guidance also warns that data associated with code-customised tables cannot simply be carried forward unless the corresponding customisations are handled appropriately.
Start by comparing the modified NAV objects with the correct standard baseline. Classify the resulting functionality by business outcome, identify fields and tables that hold required data, and map each outcome to standard Business Central, a supported app, a new AL extension, an integration, or retirement.
Treat code conversion and data migration as connected workstreams. Changing table ownership, field identity, keys, option values, dimensions, or posting logic without a data-upgrade design can block synchronisation or produce a technically successful load that fails business reconciliation.
The target should be maintainable beyond the first go-live. Extension boundaries, dependencies, permissions, test coverage, upgrade code, telemetry, documentation, and release ownership all belong in the acceptance criteria—not only whether the converted code compiles.
- Every modified object maps to a named business outcome and owner
- Every custom table and field has a keep, transform, archive, or delete decision
- Third-party apps have confirmed target versions, licences, data paths, and vendor support
- C/AL conversion scope includes reports, integrations, permissions, and scheduled processing
- Extension dependencies and object identifiers are controlled
- Upgrade code and schema synchronisation are tested with representative data
- Critical posting, costing, pricing, inventory, warehouse, and finance scenarios are automated or scripted
- Excluded legacy functionality and data have approved replacement or access arrangements
Controlled execution
A defensible migration sequence
The detailed commands vary by source and target build. The governance sequence should remain clear enough that every intermediate upgrade and migration run is repeatable, recoverable, and evidenced.
1. Baseline and decide
Back up and inventory the environment, compare custom code, profile data, choose the migration approach, and approve scope, target, intermediate versions, responsibilities, and acceptance criteria.
2. Prove the upgrade chain
Build representative non-production environments and execute every required intermediate application and data upgrade using compatible cumulative updates, documented scripts, and retained logs.
3. Prepare the target solution
Configure Business Central, convert or replace required customisations, install supported apps, implement integrations, permissions, reports, upgrade code, and operational monitoring.
4. Rehearse data and reconciliation
Run full and, where applicable, delta replications or agreed reimplementation loads. Measure duration and reconcile control totals, documents, inventory, subledgers, general ledger, and critical custom data.
5. Validate the business
Execute end-to-end UAT and non-functional checks with trained users, resolve or formally accept defects, test support and rollback, and approve the cutover decision pack.
6. Cut over and retire safely
Control the final change freeze, migration, reconciliation, user and integration enablement, hypercare, handover, and the later archive or retirement of legacy environments.
Before committing
Evidence required for a path recommendation
A recommendation should explain not only the proposed route, but why alternatives were rejected and which unknowns could still change the decision.
- Screenshot or command output proving the exact NAV and database versions
- Microsoft compatibility references captured for every selected intermediate and target build
- Modified-object comparison and C/AL or AL dependency assessment
- Third-party vendor confirmation for upgrade, replacement, data, and licensing
- Data profile and reconciliation design by company and business area
- Current-to-future process decisions with gaps and acceptance criteria
- Integration catalogue with security, volume, retry, monitoring, and cutover ownership
- Representative upgrade or migration proof with timings and unresolved issues
- Operational calendar, resource plan, training, support, rollback, and legacy-access plan
- A Statement of Work that names inclusions, exclusions, assumptions, responsibilities, and change control
Practical answers
Frequently asked questions
Can NAV 2018 migrate directly to Business Central online?
Microsoft's current NAV migration overview routes NAV 2015–2018 through Business Central on-premises version 14 and then a supported newer on-premises version before Business Central online. Validate the exact target and compatible cumulative updates in the live documentation before execution.
Why is Business Central version 14 part of the route?
Version 14 is the required bridge for older NAV or Business Central version 13 application and data upgrades and was the last release to support the C/AL development environment. Microsoft states that new customers should not use version 14 as a production destination; it is used as an upgrade stage.
Does NAV 2009 follow one standard upgrade path?
Microsoft's current standard route specifically lists NAV 2009 SP1 and NAV 2009 R2, with intermediate NAV releases before NAV 2018 and Business Central version 14. Confirm the exact NAV 2009 release, build, localisation, database, and available media before assuming support.
Can we move data without converting every C/AL customisation?
A reimplementation may move a supported subset of essential business data without carrying the whole customised application forward. Required outcomes still need to be configured, replaced, or rebuilt, and excluded history needs an approved access and retention plan. Check the current Microsoft tool scope for the target release.
Should we preserve every NAV customisation?
Usually no decision should be automatic. Compare each modification with current standard Business Central and supported apps, confirm whether the business still uses it, and evaluate the control or operational outcome. Retain, replace, redesign, or retire it deliberately.
Primary references
Official Microsoft guidance
Microsoft changes product pricing, licensing, tooling, and supported upgrade routes over time. Use these source pages to validate the current position for your target release.
Plan from evidence
Confirm the starting point before choosing the path
LeXurey's readiness check captures the first non-sensitive facts about your NAV release, user count, functions, migration status, and priorities. A supported route and exact scope still require technical discovery, testing, and an agreed Statement of Work.