Business Central vs Dynamics NAV (the Upgrade)

Dynamics NAV vs Business Central: the at-a-glance modernization table

Dynamics NAV and Business Central share a lineage — BC was forked from NAV and launched on April 2, 2018 — so on the surface the products look like close cousins. Underneath, almost everything that matters for an upgrade has changed: the customization model, the deployment model, the update cadence, the client, and the development tooling. In current Business Central UI, the module formerly called Jobs is Projects — the same capability family, modernized naming and multi-user posting behavior under 2025 release wave 1. The comparison below is the single most useful frame for understanding why a NAV to BC move is a modernization project and not an in-place patch.

Every cell is sourced from Microsoft Learn's NAV migration and customization documentation, Microsoft's published Business Central pricing, the Microsoft Fixed Lifecycle Policy for NAV, and Microsoft's July 2026 product blog on NAV, GP, and SL migration options. The detail sections that follow expand each row with the practical consequences for your code, your data, and your budget.

What actually changed from NAV to Business Central

The deepest change is architectural. In Dynamics NAV, the application was a single customizable C/AL base application — partners and customers modified core objects directly, which is why every NAV upgrade historically involved a code-merge. Business Central inverted this: the base application became a locked, Microsoft-owned artefact, and all customer and partner logic now lives in AL extensions that sit on top of it. Microsoft made this shift in two steps — version 14 was the last release to ship a customizable C/AL base app, and from version 20 onward the base app itself is delivered as AL extensions. This is the single reason a NAV to BC move is a modernization rather than an upgrade.

The deployment and update model changed just as fundamentally. NAV was an on-premises product on SQL Server that you upgraded on your own multi-year timeline. Business Central is cloud-first on Azure SaaS and runs on an evergreen cadence — two major release-wave updates per year (aligned to April and October) plus monthly minor updates, with sandbox environments for pre-production validation. Microsoft manages the infrastructure, the updates, and the backups; your job shifts from running upgrade projects to validating continuous change. For context on that shift in discipline, our ERP upgrade guide covers how the evergreen model changes the meaning of an 'upgrade' across Dynamics 365 and Odoo.

The client and tooling modernized in lockstep. NAV's heavy Windows client gave way to a browser-first web client with mobile, Teams, and Outlook surfaces, and C/SIDE was replaced by the AL Language extension in Visual Studio Code. Business Central also layers in Microsoft Copilot across finance, sales, purchasing, and operations — something NAV never had — and newer agent workloads (for example Sales Order Agent and Payables Agent on Microsoft's pricing comparison) consume Copilot Credits sold separately. Module language has also shifted: Jobs are Projects in current BC experience, with multi-user project posting improvements landing in the 2025 release waves. None of these are cosmetic; each one has a direct consequence for how your customizations, integrations, reporting, and user training survive the move.

Why the NAV support and licensing clocks are the real deadlines

If you are still on Dynamics NAV, the deciding factor is rarely features — it is the support lifecycle and the commercial runway Microsoft has now published beyond extended support. NAV is governed by Microsoft's Fixed Lifecycle Policy. For the final release, Dynamics NAV 2018, mainstream support ended on January 10, 2023; extended support, which provides security updates only, runs through January 11, 2028. After mainstream support ended, customers stopped receiving new features and most non-security updates, and the risk and technical debt compound every quarter you remain.

In July 2026 Microsoft restated the product story for NAV customers and added commercial milestones that land after the security-support cliff. Extended support still ends in January 2028. Separately, the following changes take effect on April 30, 2031 for Dynamics NAV: Annual Service Plan (Enhancement Plan and Advantage Plan) coverage ends; additional perpetual user licenses for existing NAV deployments can no longer be purchased; subscription licenses for Dynamics NAV via Solution Provider Agreement (SPA) are no longer renewable; and subscription use of Dynamics NAV through Services Provider License Agreement (SPLA) is expected to end. After that date you cannot renew Service Plans or SPA subscriptions, or buy more perpetual users for existing on-premises NAV estates.

Treat January 2028 as the security and product-support countdown and April 2031 as the commercial end of the NAV purchasing model — not as comfort to wait. Security-only updates already mean no bug fixes for non-security defects, no regulatory feature additions, and a shrinking pool of partners with active NAV skills. Practitioners and partners on X frame the same reality bluntly: untouched custom code with no remaining authors is a failure mode, not stability. More practically, the cloud migration tooling that moves NAV data into Business Central online is itself updated continuously; the older your NAV version and the longer you wait, the more upgrade hops stand between you and the cloud, and the more those hops cost.

What breaks in the move from NAV to Business Central

This is the section that decides whether your migration is a six-month project or an eighteen-month rescue. Business Central online runs extensions only, so anything in your NAV solution that relied on modifying the core application breaks unless it is converted to an AL extension. Microsoft is explicit about this in its customization migration playbook: data from tables with code customizations cannot be carried forward from Dynamics NAV unless those customizations are handled by extensions installed on both the on-premises and online environments.

Several specific platform discontinuations catch NAV customers by surprise. Codeunit 1 (ApplicationManagement) is retired — its trigger logic has moved to system events, so any code that depended on Codeunit 1 must be refactored to event subscribers. V1 extensions (the older C/AL extension format) are not supported; only V2 AL-based extensions run online, so any existing V1 extensions must be rewritten in AL. MenuSuite is deprecated, so navigation that lived in MenuSuite objects must be redefined in AL page objects. And breaking schema changes — such as removing or renaming fields — will block extension synchronization entirely, so they must be planned carefully to avoid data loss.

The most painful break for heavily customized NAV estates is .NET interoperability. .NET add-ins are not available in Business Central online, so any NAV customization that called .NET assemblies directly has to be redesigned — typically using control add-ins, Azure Functions, or external APIs to achieve the same outcome. Direct SQL Server access is also gone in the cloud: reports and integrations that read NAV tables via SQL must move to Business Central APIs, query objects, or page objects. None of these are insurmountable, but each one is work, and the inventory of these breaks is what drives your timeline and budget.

Full migration vs reimplementation: the two paths

Microsoft defines exactly two migration paths from Dynamics NAV to Business Central online, and choosing between them is the first real decision of the project. A full migration carries all data and customizations across — but it requires converting every C/AL customization to AL extensions and upgrading to the latest Business Central version. A reimplementation carries only essential business data (master data, opening balances, a subset of posted historical entries, and setup) and does not require extension conversion or upgrading beyond Business Central version 14.

Both paths share one non-negotiable first step: you must upgrade from Dynamics NAV to Business Central on-premises version 14 before you can reach the cloud, because versions earlier than 14 cannot migrate directly to Business Central online. From version 14, a full migration then continues up to Business Central on-premises version 25 or later before the cloud move, while a reimplementation can use the dedicated Business Central 14 reimplementation tool to lift only essential data into a fresh online tenant.

The decision is really about your customizations and your appetite for a clean start. Choose the full migration if your NAV customizations encode business logic you genuinely need, your C/AL is convertible to AL at acceptable cost, and you want to preserve transactional history. Choose the reimplementation if your NAV customizations are mostly legacy technical debt, you want to adopt standardized business processes and the cloud's AI and automation features, and you are willing to leave historical transactions and obsolete customizations behind. The reimplementation is often the faster, cheaper route for a customized NAV estate that has accumulated a decade of modifications — but it is a business-process decision, not a technical one, and it should be made with process owners at the table. The table below is the apples-to-apples frame partners should pressure-test with you.

Supported upgrade paths by NAV version

Because Dynamics NAV versions before version 14 cannot migrate directly to the cloud, the older your NAV release, the more upgrade hops stand between you and Business Central online. Microsoft publishes the supported standard routes, and they map cleanly to project effort: every extra hop adds weeks of code modernization and data conversion. The table below summarizes the routes from the Microsoft Learn migration documentation.

The practical implication is that your NAV version is the single biggest driver of timeline and cost. NAV 2015 through 2018 can move to Business Central on-premises version 14 in a single hop; NAV 2013 and 2013 R2 must first pass through NAV 2018; and NAV 2009 must hop through NAV 2013 or 2015, then NAV 2018, before it can even reach version 14. From version 14, all routes then require an upgrade to Business Central on-premises version 25 or later before the final cloud migration.

Converting C/AL customizations to AL extensions

If you choose the full migration path, the customization conversion is the heart of the project — and the part most likely to blow the timeline. Microsoft provides a toolchain that automates a large share of the translation, and partner experience puts the automatic conversion rate for C/AL to AL at roughly 70–85%, with the remaining 15–30% requiring manual review and rework. The standard workflow starts by exporting C/AL objects with the Export-NAVApplicationObject cmdlet using the -ExportToNewSyntax flag, running the Txt2Al conversion tool (the version that ships with Business Central version 14) to generate initial AL files, then compiling and refactoring those files in Visual Studio Code with the AL Language extension.

How each NAV object type is treated in AL is predictable, and Microsoft documents it directly. The table below summarizes the conversion approach per object type — it is the checklist your development team will work through. The deeper our BC extensions guide goes into the extension model itself, the more sense this treatment table makes, because the whole point is that you never modify the base object; you extend it or subscribe to its events.

Microsoft's customization playbook also frames the conversion as a six-checkpoint workstream, not a pure code dump: inventory and classify modified objects, ISV add-ons, and integrations by complexity; separate data-carrying customizations from behavior-only changes; package into per-tenant or AppSource extensions with a dependency chain; pilot a representative subset; regression-test with business users in a sandbox; and freeze C/AL development before cutover so all new work ships as AL. Skipping the inventory is the most expensive common mistake partners report — you cannot estimate conversion or choose full migration versus reimplementation without a complete object and integration map.

1. 01
   Inventory and classify

   Catalog every modified object, ISV add-on, and integration. Tag each as simple field addition, complex business logic, or third-party dependency. This inventory drives timeline, cost, and the full-migration versus reimplementation call.

2. 02
   Separate data from behavior

   Identify customizations that carry data (custom tables, added fields) versus behavior-only changes (page layouts, report logic). Data-carrying customizations must be handled as extensions before migration or that data cannot be carried forward online.

3. 03
   Pilot, test, then freeze C/AL

   Convert a representative subset first to validate Txt2Al output and effort. Regression-test in a BC sandbox with key users. Freeze C/AL development before final cutover — all net-new work should ship as AL extensions.

How the cloud migration itself actually works

Once you have reached a supported Business Central on-premises version, the cloud move is a structured, Microsoft-tooled process rather than a custom data-load. The replication between your on-premises database and the Business Central online tenant is managed by Azure Data Factory, with a self-hosted Integration Runtime installed on your side to bridge the two environments. You configure the connection, install the Integration Runtime, select the companies to migrate, and set a replication schedule; Azure Data Factory then runs initial and delta replications that you validate before the final cutover.

Microsoft describes the end-to-end migration in six phases: preparation for cloud migration (assess current state, plan scope, validate prerequisites, clean data, decide on company batches); the Business Central upgrade to a supported on-premises version; cloud migration setup (connection, Integration Runtime, company selection, schedule); data replication through Azure Data Factory with validation and issue-fixing; data upgrade and completion (run the data upgrade as the final step, then complete the migration to make the online environment primary); and post-migration follow-up (enable users, reconnect integrations, monitor, and optimize).

Two preparation details separate smooth migrations from painful ones. First, use the migration to reduce technical debt before you move: archive obsolete history, shrink oversized transaction and log tables, confirm that schema changes are intentional, and verify the SQL Server compatibility level is 130 or higher. Second, perform at least one full dry run in a sandbox environment before the production cutover — this is how you measure timing, surface issues, and validate results with business users before you commit. If you are migrating multiple companies, design the batches early so timing and validation repeat consistently. The phase-by-phase methodology for the surrounding implementation lives in our Business Central implementation guide.

Localization is a frequent late surprise. Country- and region-specific NAV functionality ships as localization apps in Business Central online. Confirm required localization apps exist for your target country, and convert locally customized tax, regulatory, or reporting logic to AL that is compatible with the online localization — typically owned by your implementation partner. Internal users with select Microsoft 365 plans can also get read-only Business Central data access from Teams at no additional cost when the organization holds at least one Business Central license, which is useful when you redesign who needs a full seat versus a Team Members seat after go-live.

What a NAV to Business Central migration actually costs

Because Business Central is the direct cloud successor to NAV, this is the most predictable migration in the Dynamics family — and the partner-reported ranges reflect that. A typical SMB NAV to Business Central migration runs three to six months with implementation costs in the US$30,000 to $150,000 range, with the spread driven almost entirely by your NAV version and the volume of C/AL customizations. Older NAV versions add intermediate upgrade hops and weeks of code modernization, and heavily customized estates add extension-conversion effort on top. Partner implementation averages commonly land around $40,000–$100,000+ for mid-complexity SMB moves; treat those as planning ranges, not quotes.

Your NAV version is the largest cost lever. NAV 2018 — the closest release to Business Central, with a mature web client and AL already in use — is the lowest-effort starting point, with the least manual code rework. NAV 2015 and 2016 are moderate; NAV 2013 and earlier are complex, because the extra hops through NAV 2018 add substantial code review and modernization. A useful rule of thumb: if you are running NAV 2009 through 2015, budget an additional four to eight weeks for code modernization before the cloud move even begins.

Licensing shifts from a perpetual on-premises model to per-user cloud subscriptions. Current Business Central online list pricing (USD, paid yearly) is Essentials at $80 per user per month, Premium at $110 per user per month (manufacturing and service management), and Team Members at $8 per user per month for read and workflow-approval access — with Microsoft Copilot included in Essentials and Premium. Microsoft's pricing comparison also lists Sales Order Agent and Payables Agent as requiring Copilot Credits sold separately (pay-as-you-go or prepaid). These rates reflect the November 2025 list-price update. New on-premises Business Central customers have been on subscription-only licensing since April 1, 2025 (perpetual on-prem licenses no longer sold for new customers). The per-user model makes ongoing subscription cost predictable at a known user count; our Business Central licensing guide breaks down the tiers and the Team Members economics in detail.

Choosing your NAV to Business Central path

The right path is a function of three variables: your NAV version, your customization footprint, and your appetite for a clean start. The framework below is genuinely neutral — it names when each migration model actually wins, so you can pressure-test a partner recommendation against your own situation rather than accepting a default.

1. 01
   Choose the full migration if...

   Your NAV customizations encode business logic you genuinely depend on, your C/AL is convertible to AL at acceptable cost (typically the case when 70–85% converts automatically and the remainder is bounded), and you need to preserve transactional history. This path carries all data and customizations, but it requires the full C/AL to AL conversion and the climb from Business Central on-premises version 14 up to version 25 or later before the cloud move.

2. 02
   Choose the reimplementation if...

   Your NAV customizations are mostly legacy technical debt, you want to adopt standardized processes and the cloud's AI and automation features, and you are willing to leave historical transactions behind. The Business Central 14 reimplementation tool migrates only essential data (master data, opening balances, setup) without requiring extension conversion or upgrading beyond version 14, which makes it the faster, lower-cost route for a heavily customized estate that has outgrown its own modifications.

3. 03
   Factor in your NAV version early

   If you are on NAV 2015–2018, expect a single hop to Business Central on-premises version 14 and a comparatively straightforward conversion. If you are on NAV 2013 or earlier, the intermediate hops through NAV 2018 add weeks of timeline and meaningfully raise cost — budget four to eight extra weeks for code modernization and weigh whether a reimplementation sidesteps that work entirely.

4. 04
   Move on the lifecycle clock, not on features

   NAV 2018 mainstream support ended January 10, 2023 and extended (security-only) support runs through January 11, 2028. Microsoft's July 2026 guidance further ends Service Plans and new perpetual NAV user purchases on April 30, 2031, with SPA subscriptions no longer renewable and SPLA use expected to end. Migrate on those clocks and on shrinking partner skills — not by waiting for a feature. The longer you wait, the older your version relative to continuously updated cloud tooling, and the more expensive the hops become.

Pre-migration readiness checklist for NAV estates

Before you buy licenses or book a cutover weekend, run a structured readiness pass. Microsoft's end-to-end roadmap assumes preparation first: assess current state, plan scope, validate prerequisites, clean data, and decide company batches. Partners who skip this step consistently under-scope .NET interop, direct SQL reports, and ISV add-ons that have no AppSource successor — the three items that turn a six-month plan into a rescue.

Use the checklist below as a working agenda with your partner. Every row either reduces technical debt before you touch Azure Data Factory or forces an early full-migration versus reimplementation decision. If more than half of your customizations fail the 'still needed and convertible' test, reimplementation is usually the cheaper path even when leadership's first instinct is 'upgrade everything.'

A NAV to Business Central migration planned around what breaks

Flectic implements Microsoft Dynamics 365 (including Business Central and the broader D365 family) plus Odoo for SMEs across Canada, the UK, and the US. A NAV to Business Central migration lives or dies on the customization inventory and the migration-model decision, so we start there: we catalog your modified objects, ISV add-ons, and integrations; classify each by complexity; and recommend full migration versus reimplementation based on what your code actually does — not on a default.

Our AI-Accelerated Delivery Framework is designed to deliver up to 3x faster than a conventional rollout on suitable engagements, our lifecycle support continues after go-live, and our SME focus means we work within real budgets rather than enterprise-program timelines. If you are on Dynamics NAV and weighing the move to Business Central, we will run a platform-neutral assessment of your version, your customizations, and your data, and tell you which migration model fits — including when the honest answer is a clean-start reimplementation.

Frequently asked questions