Navision to Business Central: The Migration Guide

If your business has been running Dynamics NAV for a decade or more, the migration conversation has probably come up before. For most of that time, the answer to "do we need to move now?" was "not yet." In 2026, the honest answer has changed.

Extended support has ended or is ending for every NAV version. NAV 2016 support ended on 14 April 2026. NAV 2017 ends in January 2027. NAV 2018, the final version, ends in January 2028. After that date, there will be no supported version of Dynamics NAV at all: no security patches, no compliance updates, no Microsoft support of any kind. And Bridge to Cloud 3, the Microsoft promotion that reduces BC Online licences by 30% for qualifying NAV perpetual licence holders, is open for enrolment until 31 December 2027.

This guide covers what the support lifecycle actually means, the two migration paths available, what happens to your C/AL customisations, and what Bridge to Cloud 3 involves. If you have been deferring this decision, this is the article that makes the options clear.

The NAV Support Lifecycle: What the Dates Actually Mean

Microsoft's product lifecycle for Dynamics NAV follows a fixed 10-year policy: five years of mainstream support, followed by five years of extended support. All NAV versions have passed both milestones or are approaching the end of their extended support window.

What mainstream support provided: new features, regulatory updates, non-security bug fixes, full technical support. Mainstream support has ended for all NAV versions.

What extended support provides: security patches only. No new features. No regulatory updates. Constrained technical assistance. Extended support is designed to give organisations time to plan a transition, not as a permanent operating model.

Source: Microsoft Product Lifecycle Database.

What running an unsupported NAV version means in practice: after extended support ends, the system continues to function. The data is still there. Users can still log in. But there are no further security patches, which means any vulnerability discovered after that date remains unpatched. For Irish businesses, the Revenue and GDPR compliance implications of running unpatched financial software are a practical risk. For UK businesses, the Making Tax Digital and data protection obligations carry the same implication. The risk is not theoretical; it is a question of when, not whether, a vulnerability will be discovered and exploited on unpatched software.

The other practical consequence: the pool of NAV-knowledgeable partners and developers is shrinking as staff retire and new hires are not trained in C/AL. Finding experienced support for a NAV 2016 environment is already harder than it was five years ago.

The Two Migration Paths

Moving from NAV to Business Central is not a version upgrade. The architecture changed fundamentally. The development language changed from C/AL to AL. The deployment model changed from on-premises to cloud. Because of that, every organisation has a genuine strategic choice between two distinct paths.

Path 1: Technical Upgrade

A technical upgrade migrates the existing NAV database, including compatible configuration, master data, historical transaction data, and customisations converted from C/AL to AL extensions, into a new BC environment. The goal is process continuity: the business operates on BC but the processes, data structures, and user workflows remain familiar.

When a technical upgrade is the right choice: the NAV system is well-maintained, data quality is good, processes are sound and worth preserving, and the C/AL customisations are documented and understood. A technical upgrade is generally faster and lower in upfront cost than a re-implementation.

The technical constraint to know: Microsoft's upgrade compatibility has version-specific requirements. For the most current BC version, intermediate upgrade steps may be required for older NAV versions. For businesses on NAV 2013 or earlier, the technical upgrade path involves more steps and more risk. A partner with upgrade experience can map the specific version path before the project starts (Microsoft Learn, Upgrading to Business Central).

Path 2: Re-implementation

A re-implementation starts fresh. A new BC environment is configured from current business requirements. Master data, open balances, and open transactions are migrated. Historical transaction data is archived rather than migrated into the live system. C/AL customisations are assessed: those that represent genuine value are rebuilt as AL extensions; those that were workarounds for NAV limitations are replaced by standard BC functionality.

When re-implementation is the right choice: the NAV environment is heavily customised with undocumented or poorly-maintained C/AL code; data quality is poor and a significant data cleansing project would be required for a technical upgrade; the business wants to use the migration as an opportunity to modernise processes that have been running on workarounds for years. Re-implementation takes longer and requires more intensive discovery and process mapping, but it removes accumulated technical debt and produces a cleaner, more maintainable BC environment.

The honest framing: in Zoosh Digital's experience, most NAV environments are better candidates for a technical upgrade when the system is functional and the customisations are understood. Re-implementation is the right path when a thorough customisation audit reveals that the existing C/AL code is a liability rather than an asset.

What Happens to Your C/AL Customisations

Every NAV customisation written in C/AL must be addressed as part of any migration. C/AL code cannot be deployed in Business Central Online: the language is not supported. This is not optional. Every piece of custom code must go through one of four outcomes.

Rewrite as an AL Per-Tenant Extension. The customisation is rebuilt in Business Central's AL language and deployed as a bespoke extension. This is appropriate for genuinely valuable custom functionality that BC does not replicate natively. It requires an AL developer, and the extension carries the ongoing maintenance obligations described in the customisation vs configuration guide in this series.

Replace with standard BC functionality. Business Central covers a substantially broader range of standard functionality than NAV did. Many customisations that were built to work around NAV's limitations are no longer necessary: BC handles the requirement natively through configuration. In Zoosh Digital's experience working through customisation audits with NAV clients, a meaningful proportion of C/AL code typically falls into this category.

Replace with an AppSource extension. A pre-built AppSource extension may cover the requirement. AppSource hosts a large catalogue of certified BC extensions. Checking AppSource before commissioning bespoke AL development is always the right first step.

Retire. Some customisations were built for requirements that no longer apply, or for processes that should change rather than be preserved. The migration is the right moment to retire these rather than carry them forward.

A customisation audit, completed before the migration path is chosen, maps every piece of C/AL code to one of these four outcomes. The scope and quality of the existing customisations is the single most important variable in both the migration path decision and the project budget.

Zoosh Digital has in-house AL development capability alongside BC implementation experience. This means both the migration project and the C/AL to AL code conversion are managed by one team. Partners without AL development capability must subcontract the code conversion, which adds cost, reduces accountability, and creates coordination overhead on the most technically complex part of the migration.

Bridge to Cloud 3: What It Is and Whether You Qualify

Bridge to Cloud 3 (BTC3) is a Microsoft promotion that launched on 1 January 2026 and runs until 31 December 2027. It provides a 30% discount on Business Central Online licences for qualifying existing NAV or BC on-premises perpetual licence holders. It is the successor to Bridge to Cloud 2, which provided a 40% discount and ended on 31 December 2025.

Key terms of BTC3:

• 30% discount on standard BC Online pricing for a fixed, non-cancellable 3-year term
• Dual access rights: organisations can run NAV and BC simultaneously during the migration period, eliminating the forced hard cutover
• Enhancement Plan extension: Microsoft extends the on-premises Enhancement Plan at no additional cost during the BTC3 term
• 50% discount on additional on-premises user licences during the transition period, available until 31 December 2027
• Enrolment closes 31 December 2027

Eligibility requirements:

• Must hold existing Dynamics NAV (or GP, SL, or AX) on-premises perpetual licences purchased before 1 September 2024
• Active Enhancement Plan at the time of enrolment. Based on Zoosh Digital's CSP partner experience, a 30-day grace period applies for recently lapsed plans; plans that have been inactive longer may require back-dated fees to re-establish eligibility. Contact Zoosh Digital to confirm your specific Enhancement Plan status before assuming eligibility.
• The annualised value of the BC Online subscription must equal or exceed the existing annual Enhancement Plan cost
• Must not have previously participated in Bridge to Cloud 1 or Bridge to Cloud 2
• BTC3 must be declared and enrolled through a CSP (Cloud Solution Provider) partner; it cannot be activated directly or by purchasing through Microsoft's online store

The financial case for acting within the BTC3 window: for a 20-user business on NAV with BC Essentials at €80 per user per month, the standard annual licence cost is approximately €19,200. A 30% BTC3 discount reduces that to approximately €13,440 per year for the 3-year term, a saving of approximately €17,280 over the contract period. That is before the dual access rights and the EP extension are factored in. Buying standard licences when BTC3 applies is an avoidable cost.

Sources: Microsoft announced BTC3 in September 2025, confirmed by aipartnerexec.com (September 2025). The eligibility criteria and commercial terms described above are based on Zoosh Digital's CSP partner documentation and confirmed eligibility assessments. For an eligibility check specific to your organisation, contact Zoosh Digital before purchasing any BC licences.

The Migration Project: What to Expect

A NAV to BC migration is a more complex project than a greenfield BC implementation because it adds the customisation audit, the code conversion workstream, and the data migration from an older database structure to the new BC data model.

Realistic timelines, based on Zoosh Digital's project experience:

A technical upgrade for a well-maintained NAV 2018 environment with 20 to 40 users, documented customisations, and clean data: 4 to 6 months. A re-implementation for a heavily customised NAV 2016 environment where process redesign is needed: 6 to 9 months, sometimes longer depending on the customisation scope.

The internal resource commitment: the same 20 to 30% of a named internal person's time applies here as in any BC implementation, and is frequently underestimated in migration projects. Additionally, the IT Manager or system administrator who holds the institutional knowledge of the NAV customisations is a critical resource in the customisation audit phase: their time and knowledge is not optional.

The data decision: for a technical upgrade, historical transaction data typically migrates with the system. For a re-implementation, best practice is to migrate master data and open balances only, and archive historical transaction data for reference. Full historical migration from NAV to BC in a re-implementation significantly extends the project timeline without proportionate operational benefit.

The customisation audit as the first step: for any organisation considering either migration path, the customisation audit is the essential starting point. It determines the scope of the code conversion, informs the path decision, and is the primary input into the project budget. Commissioning a migration project without a customisation audit is one of the most consistent causes of budget overruns in NAV to BC projects.

The Questions to Ask Any Migration Partner

Do you have AL development capability in-house? If the answer is no or vague, the C/AL to AL code conversion will be subcontracted. That affects cost, timeline, and accountability when something breaks.

Have you migrated from our specific NAV version before? The technical upgrade path from NAV 2016 is different from NAV 2018. A partner with experience of the specific version path is less likely to encounter surprises.

Can you confirm our BTC3 eligibility before we discuss pricing? A credible partner will check Enhancement Plan status, licence purchase date, and prior BTC3 participation before quoting standard pricing. Discovering BTC3 eligibility after a standard-price subscription has been purchased is not recoverable.

What does your customisation audit involve? A credible answer describes a structured review of all C/AL objects, a categorisation exercise (rewrite, replace, retire), and a written output that forms the basis of the project scope. A vague answer is a red flag.

FAQ

What is the difference between Dynamics NAV and Business Central?

Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central are related but distinct products. Business Central is the cloud-native successor to NAV, launched in 2018. NAV was an on-premises system developed in C/AL; Business Central runs on Microsoft Azure, is developed in AL, and receives automatic updates twice per year. Microsoft has committed Business Central as its SMB ERP platform going forward. There are no new versions of Dynamics NAV planned.

Is migrating from NAV to BC just an upgrade?

No. It is not like moving from NAV 2016 to NAV 2018. The architecture changed fundamentally: the deployment model moved from on-premises to cloud, the development language changed from C/AL to AL, and the two systems handle certain processes differently. Every C/AL customisation must be addressed. The migration is either a technical upgrade (preserving processes and historical data) or a re-implementation (fresh start from current requirements). Neither is a simple version bump.

What happens to our NAV customisations?

Every C/AL customisation must be addressed in any migration to BC. Options are: rewrite as an AL Per-Tenant Extension (bespoke development), replace with standard BC functionality if BC handles the requirement natively, replace with an AppSource extension, or retire if the requirement no longer applies. A customisation audit, completed before the migration path is chosen, determines which outcome is appropriate for each piece of custom code.

What is Bridge to Cloud 3 and do we qualify?

Bridge to Cloud 3 (BTC3) is a Microsoft promotion running from 1 January 2026 to 31 December 2027. It provides a 30% discount on BC Online licences for a fixed 3-year non-cancellable term. Eligibility requires: on-premises NAV perpetual licences purchased before 1 September 2024, an active Enhancement Plan, an annualised BC subscription value equal to or greater than the current EP cost, and no prior participation in BTC1 or BTC2. Enrolment must be completed through a CSP partner. Contact Zoosh Digital to confirm eligibility before purchasing any BC licences.

Should we do a technical upgrade or a re-implementation?

The right path depends on the health of the existing NAV environment. A technical upgrade is appropriate when the system is well-maintained, customisations are documented, data quality is good, and processes are worth preserving. Re-implementation is appropriate when customisations are undocumented or poorly maintained, data quality is poor, or the business wants to use the migration as an opportunity to redesign processes. A customisation audit is the essential first step in making this decision, and should precede any commitment to either path.

How long does a NAV to BC migration take?

Timeline depends on scope and migration path. A technical upgrade for a well-maintained NAV environment with 20 to 40 users and documented customisations typically takes 4 to 6 months. A re-implementation for a heavily customised environment requiring process redesign typically takes 6 to 9 months. The customisation audit, data quality, and internal resource availability are the primary variables. Budgeting for the realistic range, not the optimistic one, is the most consistent predictor of a migration that stays on schedule.

Closing Thought

NAV worked. For most of the businesses that have been running it, it worked well for a long time. The reason to move is not that it stopped working. It is that the support window is closing, the BTC3 pricing window has a defined end date, and the longer the migration is deferred, the smaller the pool of experienced NAV partners becomes.

The right time to start the customisation audit is before the urgency becomes pressure. A business that begins the process with enough runway makes better decisions about which path to take, which customisations to preserve, and which processes to redesign.

Zoosh Digital is an Irish-headquartered BC partner with in-house AL development capability. We have implemented BC for businesses across Ireland, the UK, and Europe, and we understand the Irish Revenue compliance requirements that a UK-based partner may not cover. If you are on NAV and want an honest assessment of your migration options, BTC3 eligibility, and customisation scope, contact Zoosh Digital for an initial conversation.

Referenced Sources

• Microsoft. Dynamics NAV product lifecycle. learn.microsoft.com/en-us/lifecycle/products/dynamics-nav.
• Microsoft Learn. Upgrading to Business Central. learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrading-to-business-central.
• Microsoft Learn. Dynamics 365 Business Central 2025 Release Wave 1 Overview. learn.microsoft.com.
• AI Partner Exec. Microsoft Announces Bridge to Cloud 3 Programme. September 2025. aipartnerexec.com.
• Microsoft. Dynamics 365 Business Central pricing and licensing. microsoft.com/en-ie/dynamics-365/products/business-central.