Preserving Customisations During a NAV to Business Central Migration

One of the most common concerns businesses raise when considering a move from Dynamics NAV to Business Central is what happens to their customisations. Over years — sometimes decades — of running NAV, most businesses have accumulated a layer of custom functionality: bespoke reports, modified workflows, industry-specific features, and adjustments to standard NAV behaviour that were built to match how the business actually operates.

The concern is understandable. These customisations represent real investment. They solve real problems. And the prospect of losing them is a significant barrier to starting a migration project.

Why NAV Customisations Cannot Be Directly Ported

Microsoft Dynamics NAV was built on a development environment called C/SIDE, with a proprietary language called C/AL. All NAV customisations — modified standard objects, custom reports, bespoke functionality — were built in this environment and exist as modifications to NAV's underlying objects.

Business Central uses a fundamentally different development architecture. Custom functionality is built as AL extensions — separate packages of code that extend Business Central without modifying its core objects. The practical consequence is that NAV customisations cannot be imported or converted into Business Central directly. The code structure is different, the deployment model is different, and the approach to extending the platform is different.

AL extensions are isolated from the core application, which means they survive Microsoft's biannual platform updates without needing to be rebuilt each time. NAV customisations, by contrast, often became upgrade obstacles that made it expensive to stay current.

The First Step: Customisation Discovery and Assessment

Before any decision can be made about which customisations to carry forward, you need a complete picture of what exists in your current NAV environment. A thorough customisation assessment covers every object that has been modified from standard NAV, every bespoke report, every custom workflow, every integration, and every third-party add-on.

For businesses that have been running NAV for ten or more years, this list can be long — and it often includes customisations that were built for business requirements that no longer exist, or that solve problems Business Central now handles natively.

The Three Outcomes for Each Customisation

During the assessment phase, every customisation is evaluated against three possible outcomes:

1. Replace with Standard Business Central Functionality

Business Central has advanced considerably since the NAV versions most businesses are running. A significant proportion of what was built as a customisation in NAV 2013, 2015, or even 2018 is now available as standard Business Central functionality. Approval workflows, document management, bank reconciliation automation, intercompany postings, production planning features — all of these have been substantially developed. An experienced partner who knows both environments thoroughly will identify replacement opportunities that a less experienced partner would miss, reducing rebuild scope significantly.

2. Rebuild as a Business Central AL Extension

Customisations that are genuinely needed and cannot be replaced by standard functionality are rebuilt as AL extensions. A well-built AL extension integrates seamlessly with Business Central's interface and data model, is maintained separately from the core application, and survives platform updates without modification. The rebuild process also gives the development team an opportunity to improve on the original implementation — addressing any performance issues and ensuring the extension follows current best practices.

3. Retire

Not everything that was built in NAV needs to follow you into Business Central. Some customisations were built for processes that have since changed. Some were workarounds for NAV limitations that no longer apply. Retiring unnecessary customisations reduces project cost and ongoing maintenance overhead.

Handling Third-Party NAV Add-Ons

Many NAV environments include third-party ISV solutions — add-ons purchased from independent software vendors to extend NAV's functionality. These need to be assessed individually during the migration. The possible outcomes:

• The ISV has released a Business Central version on Microsoft AppSource — the cleanest outcome, existing supplier relationship continues.
• The ISV's Business Central version exists but differs significantly from the NAV version — requires evaluation of whether it meets current requirements.
• The ISV has not produced a Business Central version — requires finding an alternative on AppSource or commissioning a custom rebuild.
• Standard Business Central functionality now covers what the add-on provided — the most cost-effective outcome, and more common than businesses expect.

Preserving Your Data During Migration

Customisations are not the only thing that needs to be preserved. The data that lives in your NAV environment — customer records, supplier information, transaction history, item data — also needs to reach Business Central accurately. For businesses with customised NAV data — additional fields, custom tables, or data structures added over the years — the migration needs to account for where that data should live in Business Central. The partner overseeing your migration needs to understand both what your NAV customisations were doing with data and how that data should be structured in Business Central.

Integrations: Preserving Connections to External Systems

NAV customisations often include integrations with external systems — payroll, CRM, ecommerce, EDI, warehouse management. These integrations need to be rebuilt for Business Central. Business Central's modern API infrastructure makes integrations in many cases easier to build and more robust than the equivalent NAV integrations. Native connectors exist for Shopify, payroll providers, and the Microsoft Power Platform.

The Business Central Extension Model: Why It Is Better Long-Term

In NAV, customisations were built by modifying the core application objects. When Microsoft released a NAV upgrade, those modified objects conflicted with the upgraded versions. Merging customisations with upgrades was a manual, time-consuming process — one of the main reasons NAV upgrades were expensive and businesses deferred them for years at a time.

In Business Central, AL extensions are separate from the core application. When Microsoft releases an update, extensions are tested against the new version by Microsoft's compatibility testing framework. In most cases, extensions survive updates without modification. The migration from NAV to Business Central is a move to a maintenance model that will cost less to run over time.

Getting Your Customisations Properly Assessed

The quality of the customisation assessment at the start of your migration project determines how accurate your project scope, timeline, and budget will be. NetMonkeys has delivered NAV-to-Business Central migrations from every version from 2009 to 2018. Our team understands the development patterns of each NAV era and can assess a NAV environment thoroughly to produce a migration plan that reflects what actually needs to be done.

You can also read our related guides on choosing the right Business Central implementation partner and the full cost breakdown for Business Central in 2026 to help plan your migration investment.