Direct answers

NAV to Business Central migration in 9 answers

The essentials, in question-and-answer format, before the technical detail.

QuestionDirect 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
Feasibility

Can NAV be migrated to Business Central Cloud?

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.

  • Audit of version, modules, customizations and integrations
  • Classification of each C/AL object and its AL equivalent
  • Definition of the data scope and the history to migrate
  • Recommended route with phases, milestones and validations
Get a free assessment

What is kept and what is rebuilt

Data and configurationMigrated with validation and reconciliation
C/AL customizationsRewritten as AL extensions
IntegrationsRebuilt through APIs and services
InfrastructureBecomes managed by Microsoft
NAV versions

Which NAV versions can be migrated?

Each NAV generation has a different route to Business Central Cloud. Microsoft publishes the exact status in its lifecycle policy.

VersionCharacteristicsRecommended 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.

Migration routes

NAV to Business Central Cloud migration routes

There is no single way to migrate. The right route depends on the version, the customizations and the appetite for redesign.

1. Cloud migration

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.

2. Intermediate upgrade

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.

3. Reimplementation

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.

CriterionCloud migrationIntermediate upgradeReimplementation
Source versionNAV 2018 or laterNAV 2017 and earlierAny version
Customization effortMediumHighMedium / high depending on redesign
Data preservationHighHighDefined by scope
Relative timeMediumHighMedium
Redesign opportunityLowLowHigh
Customizations

What happens to C/AL customizations?

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:

  • Already covered by standard Business Central functionality
  • Reproducible with a table extension, page extension or report extension
  • Requires rewriting on events (posting, validations, workflows)
  • Obsolete or replaced by a native ERP feature

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.

C/AL — NAV
"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.

Code conversion

C/AL to AL conversion: how customizations are rewritten

Automated conversion is a starting point, not the final result. The value is in the refactoring.

1. Initial conversion with txt2al

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

2. Refactoring into extensions

  • Base table changes to tableextension
  • Page changes to pageextension
  • Posting logic and validations to EventSubscriber
  • Enumerations to enumextension
  • Reports to report and reportextension
  • Permissions to permissionset

3. Quality validation

AL code is validated with static analyzers and tests before being published to the Business Central environment.

  • CodeCop: conventions and best practices
  • AppSourceCop: AppSource compatibility
  • PerTenantExtensionCop: cloud extensibility
  • Compilation and publication in a sandbox environment

Example: a new field from an extension

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.

Data migration

Data migration: masters, balances and history

The data scope is defined with the business, not only with IT. Everything migrated must be reconciled before go-live.

Data typeMigrated?Usual method
Masters (customers, vendors, items, accounts)YesConfiguration packages (RapidStart), Excel/CSV or API
Configuration (taxes, dimensions, number series, locations)YesConfiguration packages and templates
Opening balances (G/L, inventory, customer and vendor balances)YesOpening entries and accounting reconciliation
Open documents (orders, outstanding invoices)YesMigration of headers and lines with status
Detailed transaction historyDepending on scopeFull or summarized migration, based on volume and reporting needs
Attachments and documentsDepending on scopeSharePoint, OneDrive or external storage

How it is done

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.

Validation

  • Row counts and checksums per table and per company
  • Reconciliation of G/L and inventory balances
  • Review of customer and vendor balances and open documents
  • Formal business sign-off before cutover
Reports

What happens to NAV reports?

Reports are converted, replaced by standard ones or redirected to analytics.

Conversion to AL

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.

Report extension

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.

Analytics with Power BI

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.

Integrations

What happens to integrations?

In the cloud there is no direct database access. Integrations are rebuilt with services and APIs.

API and OData

API v2.0 (REST) and OData v4 expose the standard entities. For specific cases, custom APIs and webhooks are developed to notify business events.

Automation

Power Automate, Azure Logic Apps and Azure Functions orchestrate flows with CRM, e-commerce, banks and external systems without coupling to the database.

Authentication

Integrations authenticate with Entra ID (formerly Azure AD) and OAuth 2.0. Permissions, service applications and least-privilege scope are reviewed.

In NAVIn Business Central Cloud
Direct SQL Server accessNo direct access: only through APIs and OData
SOAP and OData v3/v4 web servicesREST API v2.0, OData v4 and custom APIs
Dataports and interchange filesXMLports in AL, APIs and Power Automate
Windows / NavUserPassword authenticationEntra 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.

Testing

Testing and validation before go-live

Every phase has acceptance criteria. Nothing reaches production without functional and data validation.

  • Unit tests of the AL extensions with test codeunits
  • Regression tests of critical processes (sales, purchasing, finance, stock)
  • UAT with key users on real scenarios
  • Reconciliation of migrated data against the original NAV
  • Integration tests and error handling
  • Verification of permissions and roles per user
  • Performance tests with representative volumes
  • Cutover rehearsal and rollback plan

Testing is not an isolated stage: it accompanies every phase. The earlier functional or data differences are found, the lower the risk at cutover.

Cutover and downtime

Cutover, downtime and operational continuity

The goal is to stop operations as little as possible and to make the cutover reversible.

Cutover plan

  • Operational freeze and period close
  • Final data synchronization (delta)
  • Validation and sign-off
  • Opening of Business Central Cloud and go-live support
  • Documented rollback plan

Downtime

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.

Timelines

How long does the NAV to Business Central migration take?

Indicative estimates per phase. The final range depends on scope.

PhaseEstimated duration
Assessment and planning1 to 3 weeks
C/AL to AL customization conversion3 to 8 weeks
Data migration and validation2 to 6 weeks
Testing and UAT2 to 4 weeks
Cutover and stabilization1 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.

Costs

How much does it cost to migrate from NAV to Business Central?

There is no single price. Cost is made up of licenses and services, and depends on these factors.

FactorImpact on cost
Number of users and edition (Essentials or Premium)Monthly or annual per-user subscription
Volume and complexity of C/AL customizationsHours of rewriting, refactoring and testing
Integrations to rebuildDevelopment of APIs, automations and authentication
Scope of data and history to migrateMigration, reconciliation and validation effort
Fiscal localization and regulatory reportsLocal extensions and compliance
Training and post go-live supportTraining and support hours

Licensing

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 pricing

Migration services

The 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 quote

See the migration cost guide →

Methodology

How we migrate your NAV to Business Central Cloud

A phased process, with validations and deliverables at each stage.

1. Assessment

Review of version, modules, C/AL objects, add-ons, integrations and data. Deliverable: feasibility report and recommended route.

2. Planning

Scope, phased schedule, priorities, acceptance criteria and data plan. Deliverable: migration plan.

3. AL conversion

Rewriting customizations as AL extensions, converting reports and refactoring on events. Deliverable: publishable extension.

4. Data migration

Loading masters, configuration, balances and open documents, with reconciliations. Deliverable: validated data.

5. Testing and UAT

Unit, regression and integration tests and user acceptance. Deliverable: validation sign-off.

6. Cutover and support

Cutover, production opening, training and post go-live support. Deliverable: stabilized operation.

Frequently asked questions

Questions about the NAV → Business Central migration

Can NAV be migrated to Business Central Cloud?

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.

Which NAV versions can be migrated?

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.

What is the migration route from NAV to Business Central?

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.

What happens to C/AL customizations?

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.

Can C/AL be converted to AL automatically?

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.

What happens to historical data?

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.

What happens to integrations?

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.

What happens to reports?

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.

How long does the NAV to Business Central migration take?

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.

How much does it cost to migrate from NAV to Business Central?

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.

How much downtime is there?

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.

What happens to my NAV license?

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).

Ready to migrate from NAV to Business Central?

Let's talk about your NAV version, your data and your customizations. We'll give you a free assessment and a recommended route.

Get a free assessment