How to Upgrade from NAV 2016 to Business Central: A Practical Guide

If you're still running Dynamics NAV 2016, you're not alone — it's one of the most common starting points we see. The good news is that NAV 2016 is close enough to the BC data model that the upgrade path is well understood. The bad news is that "well understood" doesn't mean "simple." Here's the approach we actually use.

Step 1: Inventory before you touch anything

Before writing a line of conversion code, get a full inventory of your customisations. Export your object list and separate it into three buckets:

• Standard NAV objects, unmodified — these map cleanly to BC base app and need no conversion work.
• Modified base objects — anything where you've changed standard NAV logic. These need careful handling because BC's extensibility model won't let you touch base objects directly anymore.
• Custom objects (50000+ range) — your own tables, pages, reports and codeunits. These convert to AL extensions largely as-is, with some syntax changes.

This inventory is what turns "upgrade the ERP" into a scoped, estimable project. We've seen too many upgrades stall because nobody knew what was actually customised until the conversion tooling choked on it.

Step 2: Understand what changes in the data model

NAV 2016 to BC isn't just a rename. A few structural things matter:

• Table and field ID ranges shift, and BC reserves certain ranges for Microsoft's use. Your custom objects need to move into the partner/ISV range (50000–99999, or the newer per-app ranges if you're building an AppSource extension).
• Base application modifications are no longer possible. Anything you did in NAV by editing a standard object directly has to become an event subscriber, an IsHandled pattern, or a page/table extension in BC.
• C/AL syntax differences. Things like WITH statements, certain implicit conversions, and some system functions changed or were removed in AL.

Step 3: Automate the conversion where you can

Manual C/AL-to-AL conversion is slow and error-prone at scale. We built our own conversion engine specifically because doing this by hand for the third time convinced us it shouldn't be done by hand at all. A good conversion tool should:

• Parse the C/AL object structure and classify each change (is this a pure custom addition, or a modification to base logic?)
• Route base modifications to the correct AL pattern — event subscriber for "add behaviour," IsHandled refactor for "change or skip existing behaviour"
• Flag anything it can't confidently convert for manual review, rather than silently guessing

This is the single biggest time saver in a NAV-to-BC project. Manual conversion of a mid-sized customisation set (100–200 custom objects) can take 4–6 weeks by hand. With decent tooling, that drops to under two.

Step 4: Don't skip the report and dataport conversion

Two object types get overlooked and then bite people late in the project:

Reports. NAV 2016 reports use RDLC or classic layouts. Converting these to AL means extracting the layout definition and rebuilding the dataset/columns structure. It's mechanical but tedious — exactly the kind of thing worth automating.

Dataports. These don't exist in BC at all. Every dataport needs to become an XMLport, with a proper schema/tableelement/fieldelement structure. If you have a lot of file-based imports and exports built on dataports, budget real time for this — or use tooling that does it automatically.

Step 5: Plan data migration as a rehearsed event, not a one-shot

The biggest risk in any ERP upgrade is cutover day. The fix is simple in concept and disciplined in practice: run your data migration multiple times against copies of real production data before the actual cutover. Each rehearsal should:

• Use a fresh copy of production data (not a stale test set)
• Run the full migration script end to end, timed
• Get validated by someone from the business, not just IT

By the third rehearsal, cutover day should be boring. That's the goal.

A note on India localisation

If your NAV 2016 system has India GST, TDS, TCS, or similar localisation customisations, treat this as its own workstream. These changes are almost always modifications to base posting logic, and BC's India localisation has moved on significantly since NAV 2016. Don't let a conversion tool auto-merge these into base — they need functional review against the current BC India localisation before you decide whether to keep your custom version or adopt what's now standard.

What a realistic timeline looks like

For a mid-sized NAV 2016 implementation (150–250 custom objects, single company, moderate data volume), a realistic staged timeline is:

• Assessment & inventory: 1–2 weeks
• Object conversion (with tooling): 2–4 weeks
• Testing & data migration rehearsals: 3–4 weeks
• Cutover & hypercare: 1–2 weeks

That's roughly 7–12 weeks end to end for a well-scoped project. Multi-company, high customisation, or heavy localisation can push this longer — but the structure stays the same.