The specific technical route from NAV 2018 to Business Central Online: on-premises upgrade, C/AL to AL conversion, data, SQL, reports, integrations, add-ons, testing and cutover.
The essentials of this route, in question-and-answer format, before the technical detail.
| Question | Direct answer |
|---|---|
| Can NAV 2018 be migrated to Business Central Online? | Yes. The route documented by Microsoft goes through Business Central on-premises before the cloud. See route |
| Is it a direct jump to the cloud? | Not with the current tooling: you first upgrade to Business Central on-premises (version 14, then 25 or later). See route |
| What happens to C/AL customizations? | They are converted into AL extensions. Data in custom tables requires an extension installed on-premises and online. See customizations |
| How are objects converted? | Export with ExportToNewSyntax and convert with Txt2Al version 14, plus manual refactoring. See conversion |
| What data is migrated? | Business data per company. Users, permissions and most system tables are not migrated. See data |
| What are the SQL Server requirements? | SQL Server 2016 or later and compatibility level 130 or higher. See SQL |
| What happens to reports and integrations? | Reports become AL objects; integrations move to API v2.0, OData v4 and automation, with no direct SQL access. See reports · See integrations |
| How much downtime is there? | Initial replication plus delta; the final window is bounded with prior dry runs. See downtime |
NAV 2018 was the last version released under the Dynamics NAV name. Business Central is its successor and the only product with continuous evolution, new features and integration with the Microsoft 365, Power Platform and Azure ecosystem.
According to Microsoft's official lifecycle page, Dynamics NAV 2018 followed the Fixed Lifecycle Policy: mainstream support ended on January 11, 2023, and extended support is scheduled until January 12, 2028. That calendar is the main reason to plan the migration in advance.
Support status per official documentation: Microsoft Lifecycle — Dynamics NAV 2018. Always verify the current status.
The standard route documented by Microsoft is not a direct jump: it goes through Business Central on-premises before the cloud.
The first step is to upgrade the NAV 2018 database to Business Central version 14 on-premises. It is the last version with C/AL support and the base for the AL conversion. It requires compiling and exporting the C/AL objects.
Then you upgrade to Business Central on-premises version 25 or later. Here the customizations are converted to AL extensions and add-on dependencies are resolved.
With a supported version and the extensions ready, cloud migration is configured: Azure Data Factory, Integration Runtime, data replication and the final data upgrade in the online environment.
| Starting version | Documented upgrade route |
|---|---|
| Dynamics NAV 2015 through 2018 | 1) Business Central version 14 on-premises → 2) Business Central on-premises version 25 or later → 3) Business Central Online |
| Dynamics NAV 2013 and 2013 R2 | 1) Dynamics NAV 2018 → 2) Business Central on-premises version 14 → 3) Business Central on-premises version 25 or later → 4) Business Central Online |
| Dynamics NAV 2009 SP1 and 2009 R2 | 1) Dynamics NAV 2013 or 2015 → 2) NAV 2018 → 3) Business Central on-premises version 14 → 4) Business Central on-premises version 25 or later → 5) Business Central Online |
Microsoft offers two paths. Full migration moves all data and customizations, and requires converting C/AL to AL and upgrading to the latest version. Reimplementation migrates essential data only (masters, balances, a subset of history and setup) and does not require converting extensions or upgrading beyond version 14.
In both cases the first step is to upgrade from NAV 2018 to Business Central version 14 on-premises. Reimplementation relies on the Business Central 14 tool and is intended for heavily customized databases or processes that are going to be redesigned.
Route and phases per official documentation: Migrate Dynamics NAV to Business Central online.
Business Central Online runs extensions only. Every base-code modification must be rewritten.
In NAV 2018, customizations were generally made by modifying base objects: tables, pages, codeunits and reports. That model is not compatible with the cloud, where the base code is locked. During the audit, each modified object is inventoried and classified:
A critical point: data from tables with code customizations is not carried forward to the cloud unless the customization is handled by an extension installed both on-premises and online. That is why it is important to separate data from behavior from the start.
Official detail: Customization migration guide — Dynamics NAV to Business Central Online.
Automated conversion is a starting point. The value is in compiling, refactoring and testing.
All objects are compiled and exported to the new TXT syntax, omitting system objects (IDs in the 2000000000 range):
VPCExport-NAVApplicationObject `
-DatabaseServer .\BCDEMO `
-DatabaseName "Demo Database NAV (2018)" `
-ExportToNewSyntax `
-Path "C:\export2al\baseapplication\exported.txt" `
-Filter 'Id=1..1999999999'The Txt2Al tool ships only with Business Central version 14, the last version with C/AL support. That version is used regardless of the target version:
txt2al --source="C:\export2al\baseapplication" `
--target="C:\export2al\baseapplication\al" `
--renametableextension 50101 "VPC Customer Ext"
extends Customer
{
fields
{
field(50100; "VPC Discount %"; Decimal)
{
Caption = 'VPC Discount %';
DecimalPlaces = 0 : 2;
}
}
}The AL code is set up in Visual Studio Code with the AL Language extension, compilation errors are resolved, and the code is validated with static analyzers before publishing to a sandbox environment.
Official procedure: Code Conversion from C/AL to AL · Txt2Al Conversion Tool.
Cloud data migration uses Azure Data Factory and the Integration Runtime, table by table and per company.
| Data type | Migrated? | Note |
|---|---|---|
| Business data of companies | Yes | Base application tables and extension tables that meet the requirements |
| Masters (customers, vendors, items, accounts) | Yes | Migrated table by table; configuration packages also work |
| Opening balances and setup | Yes | Validated through reconciliations before go-live |
| Transaction history | Depending on scope | Full or summarized; in reimplementation, only a subset |
| Users, permissions and most system tables | No | Not migrated; configured again in the cloud |
| Record links | No | They are associated with a user ID and are not carried over |
| Attachments and documents | Depending on scope | SharePoint, OneDrive or external storage |
The process is managed from Business Central Online and connects to the on-premises SQL database through Azure Data Factory and the Integration Runtime. The first replication is full and subsequent ones are incremental (delta). The on-premises solution remains the operative environment until the migration is completed.
Reference: Business Central on-premises to online migration overview.
The quality and order of the SQL database drive the speed and success of the migration.
There is no direct SQL database access in Business Central Online. All reading or writing from external systems goes through APIs, OData or automation. This is an architecture change, not just an infrastructure change.
They are converted to AL, replaced by standard reports or redirected to analytics.
Each C/AL report is rewritten as an AL report object. Datasets are rebuilt and RDLC or Word layouts can usually be reused with formatting and field adjustments.
When a standard Business Central report covers most of the need, it is extended to add fields, columns or filters without duplicating the object. Less code and more compatibility with updates.
Operational lists are complemented with Power BI dashboards connected to Business Central. See Power BI for Business Central →
The report inventory is part of the assessment: it identifies which reports are used, which can be retired and which should be replaced by standard ones. This avoids carrying over legacy reports that no one uses anymore.
No direct SQL access and no .NET interoperability: integrations are rebuilt with services and APIs.
API v2.0 (REST) and OData v4 expose the standard entities. For specific cases, custom APIs and webhooks are developed to notify business events.
Power Automate, Azure Logic Apps and Azure Functions orchestrate flows with CRM, e-commerce, banks and external systems without coupling to the database.
Integrations authenticate with Entra ID (formerly Azure AD) and OAuth 2.0. Permissions, service applications and least-privilege scope are reviewed.
| In NAV 2018 | In Business Central Online |
|---|---|
| Direct SQL Server access | No direct access: only through APIs and OData |
| SOAP and OData v3/v4 web services | REST API v2.0, OData v4 and custom APIs |
| Dataports and interchange files | XMLports in AL, APIs and Power Automate |
| Windows / NavUserPassword authentication | Entra ID and OAuth 2.0 |
| .NET interop and local control add-ins | Not available: control add-ins, Azure Functions or external APIs |
This is covered in more depth on the mobile and cloud integrations page and in the integrations section of services. Reference: API (v2.0) for Business Central.
A C/AL add-on does not travel to the cloud. Every product must be reviewed before the migration.
If the add-on has no AL version, the options are: rewrite its functionality as your own extension, replace it with standard Business Central functionality or another ecosystem product, or retire it if it no longer adds value. This decision directly affects effort and schedule.
Microsoft's playbook recommends classifying each item by complexity (simple field addition, complex business logic, third-party dependency) and deciding the deployment model before converting.
Every phase has acceptance criteria. Nothing reaches production without functional and data validation.
Microsoft recommends performing at least one full dry run of the migration in a sandbox environment before the production cutover, to identify issues, measure timing and validate results with business users.
The final cutover is a controlled sequence of replication, data upgrade and production opening.
Once the data upgrade has run successfully, you cannot run data replication again from an earlier version, because you risk mixing non-upgraded records with upgraded records. That is why prior validation is mandatory.
During the migration, cloud users are restricted by the Intelligent Cloud permission set to avoid writes that replication would overwrite. Make sure at least one SUPER user exists in each company before configuring the connection.
Staged replication lets you reach the cutover with the lowest possible risk.
The first replication is the longest because it copies all data; subsequent runs migrate only changes and are faster. With this approach, real downtime is concentrated in the final stretch: delta replication, data upgrade, validation and opening.
In well-run projects, that window is usually limited to a night or a weekend. The larger the data volume, the more integrations to reconnect and the more business validations required, the longer the window needed.
Indicative estimates. The final range depends on scope and is confirmed in the assessment.
| Phase | Estimated duration |
|---|---|
| Assessment and planning | 1 to 3 weeks |
| On-premises upgrade NAV 2018 → BC 14 → BC 25+ | 3 to 8 weeks |
| C/AL to AL conversion and add-ons | 3 to 8 weeks |
| Data migration and validation | 2 to 6 weeks |
| Testing, UAT and cutover rehearsal | 2 to 4 weeks |
| Cutover and stabilization | 1 to 2 weeks |
These figures are planning estimates, not schedule commitments. A NAV 2018 database with few customizations and no add-ons can be faster than one with many posting modifications and integrations. Cost is made up of per-user licenses (Essentials or Premium) and migration services, quoted by phase.
Business Central Online is purchased as a per-user subscription, not a perpetual license. Cost depends on the number of users and the edition purchased.
See Business Central pricingFor the complete view of the process, versions and route comparisons, see the main guide.
NAV to Business Central MigrationYes. Microsoft documents a migration route for Dynamics NAV 2015 through 2018 that goes through Business Central on-premises (version 14 and then version 25 or later) before migrating to Business Central Online. It is not a direct jump: it requires an intermediate on-premises upgrade and converting the C/AL customizations to AL extensions.
With the current tooling, the standard route is not direct. Microsoft states that Dynamics NAV versions cannot migrate directly to the cloud: you must first upgrade to Business Central on-premises. The documented route for NAV 2018 is NAV 2018, then Business Central version 14 on-premises, then Business Central on-premises version 25 or later, and finally Business Central Online.
All C/AL customizations must be converted into AL extensions. Data from tables with code customizations cannot be carried forward to the cloud unless the customization is handled by an extension installed both on-premises and online. Breaking schema changes such as removing or renaming fields prevent extension synchronization and must be planned carefully.
Partially. C/AL objects are exported with Export-NAVApplicationObject and the ExportToNewSyntax switch, and converted with the Txt2Al tool that ships with Business Central version 14. The result is a starting point that must be compiled, refactored and validated. Starting with Business Central version 21, Txt2Al is no longer available, so the version 14 tool is used.
Business data from one or more companies is migrated: base application tables and extension tables, provided they meet the requirements. Most system tables, users and permissions are not migrated, and record links are not carried over because they are associated with a user ID. Migration runs table by table through Azure Data Factory.
The on-premises solution must use SQL Server 2016 or later and the database must have compatibility level 130 or higher. During migration, stored procedures are added to the SQL Server instance. Archiving obsolete history, shrinking transaction and log tables, and validating schema changes before migrating are recommended.
C/AL reports are reimplemented as AL report objects. RDLC and Word layouts can usually be reused with adjustments and datasets are rebuilt. When a standard Business Central report covers most of the need, a report extension is used. Analytics can be complemented with Power BI.
Business Central Online has no direct SQL database access and no .NET interoperability. Integrations are rebuilt with REST API v2.0, OData v4, custom APIs, webhooks, Power Automate or Azure Logic Apps, with authentication based on Entra ID and OAuth 2.0.
Each add-on must be reviewed: if it is a V1 extension in C/AL it is not compatible with the cloud and must be rewritten or replaced. If the vendor publishes an AL extension for Business Central Online, it is installed and validated. Microsoft's playbook recommends inventorying and classifying all modified objects, ISV add-ons and integrations.
The process relies on staged replication: a full initial replication and then delta replications with the changes. The on-premises solution remains the operative environment until the migration is completed, and at least one sandbox dry run is recommended before the production cutover. The final window is usually limited to a night or a weekend depending on volume.
According to Microsoft's official lifecycle page, Dynamics NAV 2018 followed the Fixed Lifecycle Policy: mainstream support ended on January 11, 2023, and extended support is scheduled until January 12, 2028. Always verify the current status on Microsoft's lifecycle page.
Primary sources behind this guide.
Links point to official Microsoft documentation. Availability, tool names and routes may change across versions; always verify the current content before planning.