Dynamics NAV to Business Central: technical upgrade or honest rebuild?

With a lean, close-to-standard NAV, the route can be a genuine upgrade path. With a heavily customised NAV it is not a purely technical upgrade: years of C/AL modifications do not simply carry over into Business Central. NAV and BC share the same roots, but the break lies in the customisation model. C/AL modified the object directly, whereas AL extensions no longer touch the standard. Every legacy modification therefore needs a deliberate decision: rebuild it cleanly as an extension, return it to the standard, which is often the better route, or drop it as ballast. Usually the genuinely differentiating share is smaller than assumed. The second large block is data clean-up: over the years NAV databases accumulate duplicates, orphaned records and fields used for something they were never meant for. Carrying those over one to one cements old problems into an interface that shows every error mercilessly.

Whether it is an upgrade or a rebuild is decided by the degree of customisation, not by the technology. A largely standard-near Dynamics NAV can be lifted as a technical upgrade. For heavily customised systems, which is the norm for installations dating back to the Navision era, it is a rebuild. The reason lies in the customisation model: C/AL changes made directly in the object give way to the AL extension model, which no longer touches the standard. Every legacy customisation therefore needs its own decision: rebuild it cleanly as an AL extension, bring it back to the Business Central standard, or deliberately drop it.

Why does the break sit in the customisation model?

C/AL allowed changes directly inside the standard object. AL no longer does: an extension sits beside the standard and does not touch it. This is why a grown C/AL landscape cannot be translated, it has to be decided anew.

Source: Microsoft Learn: Development in AL

• Every legacy customisation needs a deliberate decision: rebuild cleanly as an AL extension, return to the BC standard (often the better path) or drop as ballast. Usually the truly differentiating share is smaller than assumed.
• Data cleansing is the second large block. NAV databases carry duplicates, orphaned entries and repurposed fields accumulated over years. Taking those over one to one cements old problems in an interface that shows every error without mercy. The move is the cheapest moment to shed that ballast, because it involves a data cut-off anyway.

How big is the effort, honestly?

Lifting a heavily customised NAV is closer to a rebuild with data takeover than to a click upgrade. Whoever promises a pure upgrade in a few weeks has not looked at the actual level of customisation.

A solid statement only comes after a look at the code and the data foundation, not before. In practice that means an object list of every modification, an assessment per modification, and from that a solid range with disclosed assumptions. This preparatory work takes days rather than weeks, and it determines how reliable every later commitment on dates will be.

The most common mistake here is to measure the effort by the volume of data. What matters is the number of core modifications and the documentation state, because together they determine how much has to be decided afresh on the business side. A small database with sixty core modifications costs more effort than a large one with five.

What comes along, and who decides that?

In the end the question is not technical but strategic: which grown logic is a genuine competitive advantage, and which is merely historical ballast? That decision belongs with you, because it concerns your business and not the platform.

A workable method for it is simple: for every modification, name what purpose it serves and who still confirms that purpose today. Whatever nobody can confirm is ballast, and in practice that turns out to be a surprising number of objects. This exercise costs a few days and determines months of project effort, because every special path carried along has to be tested once, documented once and then maintained for years.

Control stays on your side, with Business Central as home. Before anyone promises a technical upgrade: let us look at your NAV customisation level and your data foundation and show the honest route.

Which question begins after the upgrade?

An upgrade brings you to the current version level. That is necessary, but it is not yet the actual goal. Because a freshly migrated Business Central can be technically up to date and still reflect what your business did seven years ago.

So if you are making the move anyway, use it properly: as the moment in which the data foundation, the processes and the ownership are set up so that new requirements take weeks in future and no longer quarters. That is what we mean by Evergreen ERP.

The difference is measurable, in one single figure: the time from a business requirement to its implementation in the system. Whoever knows that figure before and after the move knows whether the project delivered more than a new version level. Without that measurement, project success stays a claim nobody can verify.