NAV to BC Migration: Technical Deep Dive 2026

If you are a Microsoft Partner evaluating a NAV to Business Central migration in 2026, or an IT director who needs a real technical picture before approving the budget, this is the article. We will skip the strategic “why migrate” — that is covered in our NAV to BC migration roadmap — and go straight into the engineering layer: AL conversion, data migration, timeline drivers, and cost composition.

Davisa has been a Microsoft Solutions Partner for Business Central since 2003, and the patterns below come from migrations across construction, manufacturing, project services and distribution.

Why NAV 2017/2018 customers are stuck (and the deadline)

The customers we see in 2026 fall into three groups, and each is stuck for a different reason.

NAV 2018 on extended support: security patches until January 2028, no functional updates, no regulatory updates. The technical environment still works, but every Spanish tax-compliance regime introduced in the last three years (SII rectifications, Verifactu, TicketBAI evolutions, Crea y Crece) is bolted on with third-party modules of varying quality. Each tax cycle the workaround gets thinner.

NAV 2017 and 2016 out of support: mainstream ended January 2022 and October 2020 respectively. Microsoft no longer ships any update, including security. SQL Server compatibility is the practical pressure: as the underlying OS and SQL versions get retired, the NAV installation drifts further from supported configurations.

NAV 2015 and older: out of any support and frequently running on hardware or virtualization layers that themselves are end-of-life. The compounding obsolescence (NAV, Windows Server, SQL Server, hypervisor, hardware) means a single component failure can take the ERP offline with no realistic recovery path.

For all three groups the engineering deadline is not 2028 — it is the next time a critical component breaks. Most of the urgency we receive in 2026 is reactive: a SQL upgrade fails, an integration partner deprecates the legacy API, a Spanish tax authority rejects a submission format. The deadline is the next outage.

The 4 migration paths (cloud SaaS, hybrid, on-prem BC, replatform)

Path 1: BC Online (SaaS). The default recommendation in 2026. Microsoft hosts, monthly cumulative updates, semiannual major releases, per-user subscription. AL extensions only, no on-premises customization. Best for organizations that can fit their requirements within the AppSource and Power Platform ecosystem.

Path 2: BC on-premises. Same product, same AL code, customer-hosted. Useful when data residency rules are unusually strict, when very specific on-prem integrations are non-negotiable, or when the customer is not ready to give up infrastructure control. The trade-off is that the IT team has to maintain the environment and apply cumulative updates manually.

Path 3: Hybrid (BC on-prem with cloud services). BC runs on-premises but connects to Power BI, Power Platform and AppSource extensions in Azure. Middle-ground option, common stop in multi-year roadmaps.

Path 4: Replatform. Migrate to a different ERP (SAP Business One, Odoo, NetSuite, Sage X3). Appears in some RFPs, but for customers already in the Microsoft stack the migration cost rarely justifies leaving the platform.

Custom code: AL conversion strategy

This is where migration projects succeed or fail. The honest classification of every NAV modification is the most valuable artifact of the discovery phase.

For each customization, the engineering team should produce one of four verdicts:

• Retire: the modification was created for a scenario that no longer exists, or for a process that BC standard now covers. 30-50% of NAV mods we audit in 2026 land here. The win is not just code reduction — it is also the elimination of training overhead and support liability.
• Replace with standard BC: BC’s standard functionality (item charges, advanced warehousing, manufacturing 365, dimensions on jobs) has expanded since the customer’s NAV version. Many mods are recreating functionality that now ships out of the box.
• Replace with AppSource extension: vertical extensions (construction, project, manufacturing, e-invoicing) cover scenarios that used to require custom development. Davisa’s catalog of dv* extensions (dvproject, dvproduction, dvgmao, dvstock, dvimpuestos, dvfactura-e) is the result of repeatedly seeing the same industry-specific gaps across migrations.
• Port to custom AL extension: only for modifications that are genuinely unique to this customer’s business and that survive the previous three filters.

For the modifications that have to be ported:

1. Run txt2al to convert C/AL syntax to AL. Output is a starting point, not a finished extension.
2. Refactor every modification that touched a base application table or page. In AL, base application changes are done through table extensions, page extensions and event subscribers — not by editing the system object.
3. Replace direct table writes with the equivalent codeunit calls. AL is stricter about transaction boundaries and locking than C/AL was.
4. Add proper telemetry. AL extensions emit signals through Session.LogMessage that surface in Application Insights — this becomes the new production observability layer.

A well-executed AL conversion typically produces 40-60% less code than the original C/AL modifications, even before retiring obsolete ones.

Data migration: dimensions, posting groups, custom tables

Data migration is the part stakeholders underestimate the most, because the technical upgrade tool makes it look mechanical.

Master data (customers, vendors, items, G/L accounts, dimensions) migrates cleanly with the standard tool. The work is on the business side: deduplication, consolidating customers split across regions, validating VAT IDs against VIES, populating new fields BC expects (electronic invoicing address, tax registration types).

Open documents (open sales orders, purchase orders, posted but unapplied invoices) migrate, but every project should plan a hard cutoff: close everything that can be closed before go-live, migrate only what is truly open. Migrating thousands of stale open orders is a frequent source of post-go-live confusion.

G/L history: opinions diverge. Some customers migrate full G/L history; others migrate opening balances plus the current and previous year, and keep NAV in read-only mode for older queries. The latter is faster and produces a cleaner BC database; the former is required if regulators or auditors expect history in the live system.

Dimensions: confirm global dimensions at migration time. Changing them post-go-live requires a full reposting, which on a year of transactions is a multi-week exercise.

Posting groups: migrate as-is but audit. Most legacy NAV deployments accumulated posting groups for one-off scenarios that were never retired.

Custom tables: each one needs a migration codeunit that maps source fields to the AL extension’s table extension or new table. This is where day-by-day project effort lives.

Real timeline: 4-8 months for medium-complexity org

A medium-complexity NAV migration in 2026 — one legal entity, moderate customization, two to four major integrations (bank, e-invoicing, e-commerce, BI) — runs 4 to 8 months end to end.

• Months 1-2: discovery, customization audit, integration inventory, data quality assessment, scope freeze.
• Months 2-4: AL conversion, extension development, integration rebuilds in parallel.
• Months 4-5: data migration cycles (typically three full dry runs), unit and integration testing.
• Month 5-6: User Acceptance Testing with the business team, defect cycles, training.
• Month 6-7: parallel run (one full close, ideally a quarter).
• Month 7-8: go-live, hypercare, post-go-live stabilization.

Multi-entity migrations and heavily customized verticals push toward 8-12 months. The variable that moves the timeline most is not the technical work — it is UAT capacity on the business side.

Cost drivers (license, hours, parallel run, training)

A typical cost composition for a medium-complexity migration:

• Consulting hours (50-65%): the biggest line. AL development, data migration scripts, integration rebuilds, configuration, testing, training. The project manager and functional lead consume a long tail of hours across all phases.
• License (10-20%): BC Essentials or Premium per user, plus AppSource extensions. Annual subscription replaces the perpetual NAV license model.
• Parallel run (10-15%): running two ERPs simultaneously costs internal team hours that often get under-budgeted.
• Training and change management (5-10%): end-user training, super-user enablement, documentation. Underinvested in most projects and a frequent cause of post-go-live productivity dips.
• Infrastructure (variable): trivial for SaaS, meaningful for on-premises BC (Azure VMs, SQL, backup, monitoring).

The cost the executive committee never sees on the proposal is the internal team’s time during UAT and parallel run. Budget realistically for two to three internal FTEs across the second half of the project.

NAV to BC migrations in 2026 are no longer experimental. The methodology is mature, the AppSource ecosystem is rich, and the technical risk is well understood. The remaining differentiator between a smooth migration and a painful one is honest scoping at the start and disciplined execution of the parallel run at the end.