Dynamics NAV (Navision) to Business Central: Upgrade or Start Clean?

Once a company running Dynamics NAV, or Navision as many still call it, decides to move to Business Central, the next question is how to approach the NAV to Business Central migration itself. There are two real paths. You can upgrade what you have and carry it forward, or start clean on standard Business Central and bring over only what you need. If you're still deciding whether and when to move at all, start with our guide to Dynamics NAV end of life.

Both paths can sound obvious. Business Central is NAV's successor, so upgrading seems natural. A decade-old system full of customizations seems like something to rebuild. Each instinct is partially right, which is why Microsoft documents both routes and why partners argue about them. In our experience, two things decide most of it: the age of your NAV version and the amount of customization built on top of it.

Two Paths to Business Central, and What Each One Carries Forward

A NAV to Business Central upgrade, which Microsoft calls a full migration, carries your existing database forward. The route runs through Business Central version 14, which marks the boundary between NAV's old C/AL code and the AL extensions Business Central uses today, and then through later releases to the current one. Along the way, every C/AL customization you keep has to be rewritten as an extension.

In return, your data, open transactions, and history come with you. Even a company headed for Business Central online upgrades on-premises first and migrates to the cloud afterward. Our NAV end-of-life guide explains why that route takes longer than it sounds.

A clean start, often called a reimplementation, configures standard Business Central from scratch and brings over essential data: customers, vendors, items, the chart of accounts, opening balances, open orders, and setup. Old customizations stay behind unless you deliberately rebuild them.

Microsoft's own NAV migration documentation frames the choice the same way, as a full migration that moves all data and customizations, or a reimplementation that moves essential data only and skips the conversion work.

The two paths overlap more than the labels suggest. A clean start is still a data migration, and an upgrade still means rewriting every customization you keep. Plenty of plans end up somewhere in between, carrying data forward while retiring most old customizations, or starting clean while keeping NAV available read-only for anyone who needs older records.

Why Partners Disagree About Which Path Is Right

Read a few Microsoft partners on this question and you'll find opposite advice.

ArcherPoint, a US Microsoft partner, argues for upgrading. In its view, an old version, a large database, heavy customization, or years of history don't make an upgrade impractical on their own, and current tools make it realistic to keep history and convert customizations. Western Computer, another US partner, leans the other way when an environment carries extensive custom logic, integrations, add-ons, and workarounds the company doesn't want to keep. For those systems, it sees a clean start as the better path.

Both are describing real projects they've delivered. The disagreement is useful because it shows the answer depends on the environment in front of you, not on a rule. Two common assumptions don't hold up:

• "A clean start is faster and cheaper." Not automatically. It avoids converting old code, but it adds process design, configuration, and data mapping that an upgrade mostly skips.
• "An old, customized system has to be rebuilt." Not automatically. Age and customization make an upgrade more expensive. They don't rule it out.

Your Customizations Decide More Than the Code

Of the two drivers, customizations usually carry more weight. NAV systems tend to be modified over the years to fit how the business worked at the time, and each modification needs one of three outcomes:

1. Rebuild it as an AL extension, when it still gives the business something standard Business Central doesn't.
2. Replace it with standard Business Central functionality or an add-on from Microsoft's AppSource marketplace, when Business Central has since closed the gap.
3. Retire it when it supported a workaround or a process the business no longer needs.

Customizations also decide what data can make the trip. In a full migration, Microsoft notes that data stored in customized tables can't come forward unless the customization behind it has been converted to an extension. Deciding to retire a customization can mean deciding to leave its records behind, so the customization review and the history decision happen together.

Once the inventory is done, the mix tells you a lot. If most customizations belong in "rebuild," an upgrade preserves real value. If most belong in "replace" or "retire," much of what an upgrade carries forward is code you'd pay to convert and then stop using, and a clean start starts to look better. That's a general take, not a rule, but it's usually the clearest signal you'll get.

The people who use each customization should help sort what makes the cut. IT can list what was built, but the business usually knows better which pieces it still depends on and which ones have quietly compounded into workarounds.

Questions That Point Toward One Path

The customization review gives you the first and usually strongest signal. Five more questions fill in the rest of the picture, and their answers won't always agree.

Do you trust your data? Clean, reconciled master data is worth carrying forward. Years of duplicate customers, obsolete items, and inconsistent records would simply move into the new system with an upgrade, while a clean start gives you a natural point to clean up data before anything is loaded in the new system.

How much history do people actually use? If users, auditors, or analysts drill into old transactions as part of daily work, an upgrade keeps that history native. If the need is only occasional, opening balances plus read-only access to NAV or a reporting copy often covers it. Ask the people who use the history, not just the people who own the system.

Do your processes still fit? If your processes work and the goal is mainly a technical move, that favors an upgrade. If the move is a chance to redesign processes, controls, the chart of accounts, or dimensions, then a clean start gives you room to do it even though the design work adds time.

How old is your version, and what's your deadline? Older versions add upgrade steps. NAV 2013, for example, has to reach NAV 2018 before it can move to Business Central, which raises the cost of carrying everything forward. The deadline cuts both ways, since an upgrade avoids redesign decisions while a clean start avoids converting old code, and neither is automatically faster. For where your version stands, see NAV support dates by version to learn more.

What do your add-ons and integrations need? If your add-ons have Business Central versions and your integrations can be updated, that supports an upgrade. If a critical add-on has no equivalent, or interfaces need redesigning anyway, the case for a clean start gets stronger.

When the answers split, the plan usually should too: carry some things forward and rebuild others.

Online or On-Premises Is a Separate Decision

Where Business Central runs is a different question from how you get there. Either path can land online or on-premises, and treating them as one decision can push a company into the wrong path just because it prefers the cloud.

The two decisions do overlap in one case. An upgrade headed for Business Central online still passes through Business Central on-premises before the cloud migration.

Licensing also depends on staying current. Microsoft offers NAV customers with an active Enhancement Plan a license transition to Business Central on-premises, and the Bridge to Cloud 3 discount for moves online requires an active plan as well. That discount closes to new enrollments on December 31, 2027. In the meantime, keep the Enhancement Plan active while you decide.

What to Settle Before You Choose a Path

The questions above are only as good as the information behind them. Before choosing, pull together:

• Every customization, with the people who rely on it
• Your add-ons and integrations, and whether each has a Business Central equivalent
• An honest read on data quality
• Who uses historical records, and how often

Then decide where Business Central will run as its own question.

Whichever path you choose, rehearse it. For the cloud migration, Microsoft recommends a full dry run in a sandbox before the production cutover, and the same discipline applies to a clean start's data load.

Ascendex helps NAV companies choose the right path and then see it through go-live. Often the first step is an ERP assessment, which gives you the customization, data, and integration picture this decision depends on. See how we handle NAV to Business Central upgrades. And always feel free to contact us to have a more in-depth discussion.