Upgrading Dynamics NAV to Business Central: A Technical Roadmap

Plenty of businesses still run on Microsoft Dynamics NAV. It works, until it doesn't: mainstream support has ended for every NAV version, finding C/SIDE developers is getting harder, and modern integrations expect REST APIs and the cloud. Dynamics 365 Business Central is the natural next step, but a NAV upgrade is a software project and should be planned like one.

This is the roadmap I follow when upgrading NAV solutions to Business Central, based on projects that went from NAV 2009 R2 and NAV 2015 to modern Business Central versions.

Why move from NAV to Business Central?

• Supported, evergreen platform. Business Central gets two major releases a year plus monthly updates, so you stop paying for one large "re-upgrade" every few years.
• Extensions instead of code modifications. Customisations live in AL extensions that sit on top of the base application rather than changing it, which makes future updates far cheaper.
• Cloud and APIs. Standard REST/OData APIs, Power Platform connectors and Microsoft Entra ID authentication make integration a configuration task rather than a custom project.
• A modern user experience in the browser, on tablets and phones, with Microsoft 365 integration built in.

Know your upgrade path

The first question is always which version are you on? NAV was rebuilt several times, and the route to Business Central depends on where you start. Broadly:

Step 1: Assess and inventory

A good upgrade starts with a clear picture of what you have. Before writing any code, build an inventory of:

• Modified and custom objects. Compare your database against a clean standard database of the same version and localisation to find the real delta.
• ISV add-ons. Check whether each vendor offers a Business Central version. Many do, and some are now covered by standard features.
• Integrations. Web services, file exchanges, direct SQL access and .NET interop. Direct SQL and client-side .NET won't work in the cloud, so plan replacements.
• Reports and documents that users depend on, such as invoices, picking lists and statutory reports.
• Data volume and history. Decide how much history to bring across and what to archive.

Expect to drop a good share of old customisations. Features added to NAV years ago are often standard in Business Central now, or simply no longer used. Every customisation you retire is code you never have to maintain again.

Step 2: Convert C/AL to AL extensions

Business Central 15 and later run only AL. For solutions that reach Business Central 14, Microsoft provides tooling to move C/AL code across:

1. Export the objects from the C/SIDE development environment in the new syntax (finsql.exe with the ExportToNewSyntax command).
2. Convert the exported text files to .al files with the Txt2Al converter.
3. Refactor the result into proper extensions: table extensions, page extensions and event subscribers instead of changes to standard objects.

# Convert C/AL exported in the new syntax into AL files
txt2al --source="C:\Upgrade\CAL" --target="C:\Upgrade\AL" --rename --extensionStartId=50100

The converter gives you a starting point, not a finished product. The real work is re-designing modifications as events. If the standard application has no event where you need one, look for a nearby event or an alternative design first. In the cloud you can't modify the base application.

Step 3: Upgrade data with upgrade codeunits

When table structures change, for example a custom field moving to a new table extension or an Option becoming an Enum, the data has to follow. In AL that's the job of upgrade codeunits. Combine them with upgrade tags so each step runs exactly once:

codeunit 50150 "DS Upgrade Loyalty"
{
    Subtype = Upgrade;

    trigger OnUpgradePerCompany()
    var
        UpgradeTag: Codeunit "Upgrade Tag";
    begin
        if UpgradeTag.HasUpgradeTag(LoyaltyTierUpgradeTag()) then
            exit;

        MigrateLoyaltyTier();
        UpgradeTag.SetUpgradeTag(LoyaltyTierUpgradeTag());
    end;

    local procedure MigrateLoyaltyTier()
    var
        Customer: Record Customer;
    begin
        Customer.SetFilter("DS Loyalty Points", '>=%1', 1000);
        Customer.ModifyAll("DS Loyalty Tier", Enum::"DS Loyalty Tier"::Gold);
    end;

    local procedure LoyaltyTierUpgradeTag(): Code[250]
    begin
        exit('DS-LOYALTY-TIER-20261007');
    end;

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Upgrade Tag", 'OnGetPerCompanyUpgradeTags', '', false, false)]
    local procedure RegisterPerCompanyTags(var PerCompanyUpgradeTags: List of [Code[250]])
    begin
        // New companies start clean, so the upgrade step is marked as done
        PerCompanyUpgradeTags.Add(LoyaltyTierUpgradeTag());
    end;
}

Rehearse the data upgrade on a copy of production and time it. The duration of the data upgrade decides how long your go-live weekend has to be.

Step 4: Migrate the reports

Reports are where users notice an upgrade first. Classic NAV 2009 reports (the Classic client "sections" designer) don't carry over at all. They have to be rebuilt as RDLC or Word layouts on report objects. For newer versions, existing RDLC layouts often convert but still need testing.

• Prefer report extensions and custom layouts over copying standard reports, so you keep receiving Microsoft's fixes.
• Use Word layouts for documents that business users want to tweak themselves.
• Compare old and new output side by side with real data, especially totals, VAT and currency formatting.

Step 5: Test in sandboxes

Use Docker containers with BcContainerHelper (or Business Central online sandboxes) to build disposable test environments. Automate the repetitive parts with AL test codeunits, then run user acceptance testing with key users on realistic data: posting, period-end, reports and every integration.

Step 6: Plan the cut-over

• Freeze master data changes and agree on the last transaction date in NAV.
• Take a full backup and keep the old system read-only for reference.
• Run the data upgrade using the timings from your rehearsal.
• Reconcile: G/L balances, open customer and vendor entries, inventory value.
• Smoke-test the integrations, then open the system to users.
• Plan for hyper-care, with a developer on standby for the first weeks.

Common pitfalls

• Lifting and shifting every customisation instead of questioning whether it is still needed.
• Underestimating reports, especially when coming from NAV 2009 R2.
• Forgetting integrations that relied on direct SQL access or client-side .NET assemblies.
• No rehearsal, which leads to a go-live weekend that runs over.

Wrapping up

A NAV to Business Central upgrade is a chance to clean house: fewer customisations, cleaner code and a platform that stays current. With a clear inventory, upgrade-safe extensions, rehearsed data upgrades and a solid cut-over plan, it can be a predictable project instead of a risky one.

Planning an upgrade from Dynamics NAV? Get in touch. I'm happy to look at your current version and help you pick the right path.

Diwas Shrestha

.NET developer and Dynamics 365 Business Central technical consultant in Kathmandu, Nepal. I build AL extensions, upgrade NAV systems and integrate ERP with .NET applications. Work with me →