Migration is not modernization: know which project you are buying

Two very different projects travel under the same name. One moves an estate to a new platform with as little change as possible. The other uses the move to change how the system works: what is customized, how data is shaped, where work happens. Both are legitimate. The trouble starts when a business buys one and expects the other.

What the platform requires either way

The move from Dynamics NAV to Business Central is not just a copy, whichever project you choose. Microsoft's upgrade guidance for Business Central online is specific: you can upgrade from supported versions of NAV on-premises provided that your application customization is handled by extensions, and data from tables with code customizations cannot be carried forward. The documented route is to upgrade to Business Central version 14 or later on-premises first, convert non-standard functionality and customizations to apps and per-tenant extensions, and then run the cloud migration tool.

So every customization has to be looked at. That is the moment the two projects separate: a migration converts each one as faithfully as it can, while a modernization asks whether each one should exist at all.

Retain, redesign or retire

The film sorts customizations into three piles, and in our practice that sorting is the most valuable hour of the whole project:

• Retain: it still does something the business needs, the standard product does not do it, and it works. Convert it to an extension as it is.
• Redesign: the need is real but the way it was built no longer fits, because the standard product now covers most of it, or it was built around a limitation that no longer exists, or it does per-record work that could be done once.
• Retire: nobody uses it, the process it served has changed, or the standard product now does it. Turn it off before the move, not after.

Retiring is the cheapest line in any upgrade budget, and the most often skipped, because nobody wants to be the person who removed something. Usage evidence settles most of those arguments: if a report has not been run this year and the page has no views, the conversation becomes short.

Why the label matters to the budget

A migration carries the data model with it. If the estate was slow because of how data was shaped or how customizations worked, it will be slow in the new place too, now with a monthly bill. A modernization costs more and takes longer because it changes things, and it is sometimes not worth doing. Either can be the right decision. What goes wrong is a migration budget with modernization expectations, or a modernization budget spent on converting code nobody uses.

What usually lands in each pile

Every estate is different, but the same shapes recur. Added fields and simple page changes usually retain cleanly: in the extension model they become table and page extensions with little drama. Custom reports are often the largest retire pile, because years of releases have added standard reports that cover most of what was once built by hand, and because nobody has checked which custom ones are still run.

The redesign pile is usually where the risk sits: changes made inside standard posting or document logic. In the extension model, changes are made around the standard application rather than inside it, so a modification that rewrote a posting routine has to be rethought, not translated line by line. Those are the items to estimate first and most carefully, because they decide whether the timeline is realistic.

Integrations deserve their own line on the list. They are customizations that live partly outside the system, and they are the ones most likely to be forgotten until the first morning after go-live.

The traps

• Converting everything because it exists. Every customization carried forward is code to maintain through every future update.
• Calling the project modernization because the platform is new. A new platform with the old design is a migration.
• Deciding customizations by who shouts loudest rather than by usage and value.

Five checks for this week

• List every customization in the current estate: objects changed, objects added, reports, integrations.
• For each, find the evidence of use: page views, report runs, the process it serves and its owner.
• Sort each into retain, redesign or retire, and write one sentence on why.
• Check the supported upgrade path for your exact NAV version before planning dates.
• Write down, in one line, whether this project is a migration or a modernization, and make sure the budget and the expectations say the same thing.

Veltheon is founder-led, based in Ontario, and works on Business Central and NAV, SQL Server and Azure. If one of these sounded like your estate, the first conversation is free and starts with the evidence you already have.