NAV to Business Central migration: a practical roadmap

Why the timing matters

Mainstream support for the last NAV release, NAV 2018, ended in January 2023, and extended support runs out in January 2028. New features, connectors and regulatory updates land in Business Central only. Every year on NAV adds integration workarounds and makes the eventual code conversion larger, because customisations keep accumulating in C/AL.

That does not mean you should rush. A well-planned migration of a moderately customised NAV database typically takes two to six months. A rushed one takes longer, because rework replaces planning.

Step 1 — Assessment and inventory

Everything starts with an honest inventory: which objects were customised, which add-ons are installed, which integrations exist, and which of those are actually used. Tooling helps here — object comparisons against the standard application and code-usage analysis quickly separate living customisations from dead weight.

The output of this phase is a migration plan with a fixed-price estimate per milestone: what moves to standard functionality, what becomes an extension, what gets retired, and how data will travel.

Step 2 — Choose the target: SaaS or on-premises

Business Central online (SaaS) is the default answer for most mid-market companies: no servers, automatic updates twice a year, and the full Microsoft cloud around it. On-premises or hosted BC remains valid where regulatory or integration constraints demand it.

The target shapes the technical work. SaaS requires all custom code to be delivered as AL extensions and to be cloud-compliant, so the decision belongs at the start of the project, not the end.

Step 3 — Rationalise before you convert

The cheapest code to migrate is code you delete. Fifteen-year-old NAV databases usually contain customisations that current Business Central covers as standard functionality. Mapping each customisation to a keep, replace-with-standard or retire decision routinely shrinks the conversion scope by 30 to 50 percent.

Step 4 — C/AL to AL conversion

Remaining customisations are transformed from C/AL into AL extensions. Microsoft's conversion tooling gives a starting point, but real work is in refactoring: replacing base-object modifications with events and table extensions, rewriting .NET interop, and restructuring reports.

We covered this phase in depth in our C/AL to AL conversion guide — it is usually the largest technical work package of the migration.

Step 5 — Data migration

There are two practical strategies. Full upgrades carry all history through Microsoft's upgrade path, version by version. Lift-and-shift migrations move master data and open entries into a clean Business Central company, leaving history in a read-only archive.

Lift-and-shift is faster and cleaner for heavily customised or very old databases; full history upgrades suit organisations with audit requirements on transactional history. Either way, plan at least two trial migration runs before the real one.

Step 6 — Testing, cutover and hypercare

User acceptance testing against real converted data is where migrations succeed or fail. Key users walk their actual processes — order to cash, purchase to pay, month-end — in the new environment while the old one still runs.

Cutover itself is a weekend: final data run, reconciliation, integration switch-over, go. The two to four weeks after go-live are hypercare: short response lines, daily check-ins, and fast fixes while the organisation settles in.

What it costs and how long it takes

The honest answer is that scope drives everything: number of live customisations, add-ons, integrations and companies. As orientation, a lightly customised single-company NAV 2016+ database can reach Business Central SaaS in eight to twelve weeks; a heavily customised multi-company environment is a four-to-six-month programme.

A fixed-price, milestone-based model keeps this predictable: you know the price of the assessment before you start, and the price of the migration before you commit to it.