NAV to Business Central: what to actually plan for

The mechanics of moving from Dynamics NAV to Business Central are well understood. The risk almost never lives in the tooling — it lives in the decisions around it. Having taken a number of long-standing NAV deployments across to BC, here's what I make sure gets planned for before anyone touches a database.

Inventory your customisations honestly — then decide what to leave behind

Every NAV system accumulates years of modifications, and a surprising share of them are obsolete: workarounds for problems BC now solves natively, features nobody uses, reports superseded three finance managers ago. An upgrade is the one moment you're allowed to shed that weight. Catalogue every customisation, then put each one into three buckets: bring it, rebuild it better, or drop it. The instinct to "migrate everything" is how projects double in cost.

C/AL to AL is a re-platform, not a translation

It's tempting to think of the code move as a line-by-line conversion. It isn't. BC's extension model means your old customisations that edited the base application directly now have to be re-expressed as events and extensions that sit alongside it. That's a genuine redesign for anything non-trivial — and it's a good thing, because the result is upgrade-safe in a way the original never was. Budget for it as development, not translation.

Cleanse data before the move, not during

Whatever mess exists in your NAV data will be faithfully carried into BC unless you deal with it first — duplicate customers, dead items, dimension values nobody recognises. Cleansing in the source, ahead of time, is far easier than trying to fix it mid-migration when everything is in flight. Run test migrations early and reconcile the numbers; the first one always surfaces something.

Plan the cutover, and keep a way back

A phased approach with a period of parallel running takes nerve and effort, but it's what lets people trust the new system. Decide in advance how you'll reconcile balances, who signs off, and — crucially — what your rollback looks like if go-live weekend goes sideways. Most projects can get critical downtime down to a day or two with proper planning.

Mind the hidden long poles

Integrations and reports are where migrations quietly overrun. That EDI feed, the bespoke invoice layout, the spreadsheet that pulls from NAV overnight — each is a small project of its own, and they tend to be discovered late. Find them at the assessment stage, not during UAT.

Done well, a NAV-to-BC migration is less a lift-and-shift and more a spring clean with a new platform at the end of it. The businesses that get the most from it are the ones that treat it as a chance to simplify, not just to survive the jump.