Technical guide and professional service to move from NAV to Business Central Cloud without losing data, processes or operational continuity.
The essentials, in question-and-answer format, before the technical detail.
| Question | Direct answer |
|---|---|
| Can NAV be migrated to Business Central Cloud? | Yes. NAV 2018 and later have an official migration path to Business Central online. Earlier versions require an intermediate upgrade or a reimplementation. See details |
| Which NAV versions can be migrated? | From NAV 2018 direct migration is viable; NAV 2017, 2016, 2015, 2013 and 2009 are handled with a staged upgrade or a reimplementation. See versions |
| What is the migration route? | Cloud migration with Microsoft tooling, an intermediate on-premises upgrade, or a reimplementation in BC Cloud. See routes |
| What happens to customizations? | They are rewritten as AL extensions. Code that modifies base objects cannot be migrated, because the cloud does not allow it. See customizations |
| What happens to historical data? | Master data, configuration, opening balances and open documents are migrated. Detailed history is defined by scope. See data |
| How much does it cost? | It depends on users, customizations, integrations, data and localization. It is quoted after the assessment. See costs |
| How long does it take? | A standard migration is estimated at 4 to 12 weeks, depending on database, customizations and integrations. See timelines |
| What happens to integrations? | They are rebuilt with REST API v2.0, OData v4, custom APIs, webhooks or Power Automate. See integrations |
| What happens to reports? | They are converted into AL report objects, reusing RDLC or Word layouts where possible. See reports |
Yes. Business Central is the cloud successor to Dynamics NAV and Microsoft maintains a migration path for supported versions. Feasibility depends on the NAV version, the level of customization and how the integrations are built.
The key difference from a traditional upgrade is the extension model: Business Central Cloud does not allow modifying the base code. Every customization must live in an AL extension. That requires an upfront review and classification of each customization.
Each NAV generation has a different route to Business Central Cloud. Microsoft publishes the exact status in its lifecycle policy.
| Version | Characteristics | Recommended route to BC Cloud |
|---|---|---|
| NAV 2018 | Last version under the NAV name. Three-tier architecture on SQL Server, web services and extensions v2. | Upgrade to Business Central on-premises (version 14 and then 25 or later) and cloud migration, with C/AL to AL conversion. See NAV 2018 guide → |
| NAV 2017 | Extensions v2, deeper Office 365 integration and a consolidated web client. | Intermediate upgrade to NAV 2018 or Business Central on-premises, then cloud migration. |
| NAV 2015 / 2016 | Mature web client, Power BI improvements and early extensions. | Staged upgrade or reimplementation, depending on the volume of customizations. |
| NAV 2013 / 2013 R2 | Three-tier architecture and web services; older code base. | Staged upgrade with prior assessment, or reimplementation in BC. |
| NAV 2009 and earlier | Classic client and RoleTailored client, with no active support. | Reimplementation in Business Central with data migration and redesigned customizations. |
Version is not the only criterion: a NAV 2016 database with no customizations can be simpler to migrate than a heavily modified NAV 2018. That is why the technical assessment is the first step of any project.
There is no single way to migrate. The right route depends on the version, the customizations and the appetite for redesign.
For NAV 2018 and later. Microsoft's migration tooling replicates the on-premises data to a Business Central online environment, allowing migration by company and by stage. Customizations are rewritten as AL extensions.
For versions earlier than NAV 2018. The database is first upgraded on-premises to NAV 2018 or to a supported Business Central on-premises release, and from there migrated to the cloud. It preserves more code and data, but lengthens the project.
A clean Business Central Cloud environment is created, master data, balances and open documents are migrated, and only the customizations that add value are rewritten. Recommended for legacy databases or processes to be redesigned.
| Criterion | Cloud migration | Intermediate upgrade | Reimplementation |
|---|---|---|---|
| Source version | NAV 2018 or later | NAV 2017 and earlier | Any version |
| Customization effort | Medium | High | Medium / high depending on redesign |
| Data preservation | High | High | Defined by scope |
| Relative time | Medium | High | Medium |
| Redesign opportunity | Low | Low | High |
In NAV, customizations were generally made by modifying base objects: tables, pages, codeunits and reports. That model is not compatible with Business Central Cloud, where the base code is locked and every extension must be independent and upgrade-safe.
During the audit, each C/AL modification is classified into one of these categories:
This analysis avoids rewriting unnecessary code and is the basis of the effort estimate. It is covered in more depth on the AL extension development page.
"Line Discount %" :=
GetCustomerDiscount("Sell-to Customer No.");
AL — Business Central (extension)
codeunit 50100 "VPC Sales Discount"
{
[EventSubscriber(ObjectType::Table,
Database::"Sales Line",
'OnAfterValidateEvent', 'Quantity',
false, false)]
local procedure ApplyDiscountOnQuantity(
var Rec: Record "Sales Line")
begin
Rec."Line Discount %" :=
GetCustomerDiscount(Rec."Sell-to Customer No.");
end;
local procedure GetCustomerDiscount(
CustomerNo: Code[20]): Decimal
var
Customer: Record Customer;
begin
if Customer.Get(CustomerNo) then
exit(Customer."VPC Discount %");
exit(0);
end;
}
Instead of modifying the base table, the logic hooks into an event and new fields are added from an extension.
Automated conversion is a starting point, not the final result. The value is in the refactoring.
C/AL objects are exported as text and converted to AL syntax with Microsoft's txt2al tool. The output is reviewed object by object.
txt2al --source="C:\NAV\Objects" --target="C:\BC\AL" --rename
AL code is validated with static analyzers and tests before being published to the Business Central environment.
tableextension 50101 "VPC Customer Ext"
extends Customer
{
fields
{
field(50100; "VPC Discount %"; Decimal)
{
Caption = 'VPC Discount %';
DecimalPlaces = 0 : 2;
}
}
}
Automated conversion does not solve third-party add-on dependencies, deep posting changes or integrations. Those points are handled as specific development work within the migration plan.
The data scope is defined with the business, not only with IT. Everything migrated must be reconciled before go-live.
| Data type | Migrated? | Usual method |
|---|---|---|
| Masters (customers, vendors, items, accounts) | Yes | Configuration packages (RapidStart), Excel/CSV or API |
| Configuration (taxes, dimensions, number series, locations) | Yes | Configuration packages and templates |
| Opening balances (G/L, inventory, customer and vendor balances) | Yes | Opening entries and accounting reconciliation |
| Open documents (orders, outstanding invoices) | Yes | Migration of headers and lines with status |
| Detailed transaction history | Depending on scope | Full or summarized migration, based on volume and reporting needs |
| Attachments and documents | Depending on scope | SharePoint, OneDrive or external storage |
For NAV 2018 and later, the cloud migration tooling replicates the on-premises database and allows copying entire companies. For reimplementations, configuration packages load masters and opening balances are posted through opening entries. Large volumes can be migrated with codeunits and APIs.
Reports are converted, replaced by standard ones 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 can be 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.
In the cloud there is no direct database access. 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 | In Business Central Cloud |
|---|---|
| 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 |
This is covered in more depth on the mobile and cloud integrations page and in the integrations section of services.
Every phase has acceptance criteria. Nothing reaches production without functional and data validation.
Testing is not an isolated stage: it accompanies every phase. The earlier functional or data differences are found, the lower the risk at cutover.
The goal is to stop operations as little as possible and to make the cutover reversible.
With the migration tooling and incremental replication, the final cutover is reduced to a bounded window: typically one night or a weekend. The larger the data volume and the more integrations to reconnect, the longer the window needed.
Phased migration allows parallel validation so the cutover is reached with the lowest possible risk. Downtime does not depend on technology alone: business validation time also matters.
Indicative estimates per phase. The final range depends on scope.
| Phase | Estimated duration |
|---|---|
| Assessment and planning | 1 to 3 weeks |
| C/AL to AL customization conversion | 3 to 8 weeks |
| Data migration and validation | 2 to 6 weeks |
| Testing and UAT | 2 to 4 weeks |
| Cutover and stabilization | 1 to 2 weeks |
A standard migration is usually in the 4 to 12 week range overall, with phases that can overlap. Databases with many customizations, complex integrations or extensive history require more time. These figures are planning estimates, not schedule commitments: the timeline is confirmed after the assessment.
There is no single price. Cost is made up of licenses and services, and depends on these factors.
| Factor | Impact on cost |
|---|---|
| Number of users and edition (Essentials or Premium) | Monthly or annual per-user subscription |
| Volume and complexity of C/AL customizations | Hours of rewriting, refactoring and testing |
| Integrations to rebuild | Development of APIs, automations and authentication |
| Scope of data and history to migrate | Migration, reconciliation and validation effort |
| Fiscal localization and regulatory reports | Local extensions and compliance |
| Training and post go-live support | Training and support hours |
Business Central Cloud is purchased as a subscription, not a perpetual license. Microsoft publishes transition programs for NAV customers. License cost depends on the number of users and the edition purchased.
See Business Central pricingThe service includes assessment, customization conversion, data migration, reports, integrations, testing and cutover. It is quoted by scope and by phase, so you know what is delivered at each stage.
Request a quoteA phased process, with validations and deliverables at each stage.
Review of version, modules, C/AL objects, add-ons, integrations and data. Deliverable: feasibility report and recommended route.
Scope, phased schedule, priorities, acceptance criteria and data plan. Deliverable: migration plan.
Rewriting customizations as AL extensions, converting reports and refactoring on events. Deliverable: publishable extension.
Loading masters, configuration, balances and open documents, with reconciliations. Deliverable: validated data.
Unit, regression and integration tests and user acceptance. Deliverable: validation sign-off.
Cutover, production opening, training and post go-live support. Deliverable: stabilized operation.
Yes. NAV 2018 and later versions have an official migration path to Business Central online. Earlier versions (NAV 2017, 2016, 2015, 2013, 2013 R2 and 2009) require an intermediate upgrade to NAV 2018 or to Business Central on-premises, or a reimplementation. Feasibility is confirmed in the initial assessment.
Direct migration with Microsoft tooling is available for NAV 2018 and later. Older versions are migrated through a staged upgrade or a reimplementation. The decision depends on the level of C/AL customization, the integrations and the quality of the database.
There are three main routes: cloud migration with Microsoft tooling (NAV 2018 or later), an intermediate on-premises upgrade followed by migration, or a reimplementation in Business Central Cloud. The route is defined by version, customizations, integrations and data volume.
They are classified and rewritten as AL extensions. Changes made directly to NAV base objects cannot be carried over as-is to Business Central Cloud, because the cloud does not allow modifying the base code. They are replaced by table extensions, page extensions and event subscribers.
Partially. The txt2al tool converts C/AL objects exported as text into AL syntax and serves as a starting point, but the output must be refactored manually: events, extensions, permissions and validation with analyzers such as CodeCop and AppSourceCop.
Master data, configuration, opening balances and open documents are migrated. Detailed history can be migrated in full or summarized depending on volume, reporting needs and cost. Integrity is validated through reconciliations before go-live.
Business Central Cloud does not allow direct SQL database access. Integrations are rebuilt using API v2.0 (REST), OData v4, custom APIs, webhooks, Power Automate or Azure Logic Apps, reviewing Entra ID authentication and data formats.
C/AL reports are converted into AL report objects. RDLC and Word layouts can usually be reused with adjustments and datasets are rebuilt. Some custom reports are replaced by standard reports with a report extension, and analytics can move to Power BI.
A standard migration is usually estimated at 4 to 12 weeks. The range depends on database size, the number and complexity of customizations, integrations and the scope of history. The project is planned in phases with validations.
It depends on scope: number of users and licenses, volume of C/AL customizations, integrations, data to migrate, fiscal localization and training. There is no single price; it is quoted after the initial assessment.
Downtime is concentrated in the final cutover. With incremental replication and phased migration, the cutover window is usually limited to nights or a weekend, depending on data volume and prior validations.
Business Central Cloud runs on a per-user subscription, not a perpetual license. Microsoft publishes transition programs for NAV customers. License cost is defined by the number of users and the edition (Essentials or Premium).