Eight months from NAV to Business Central SaaS. Three years to make it safe to touch.

The part everybody sells you is the part that takes a day

Microsoft ships a converter. You point it at C/AL, it emits AL. On this project that step fits inside a single working day: the entire custom codebase, back out as AL that compiles.

If a migration were the conversion, the project would have finished that week.

Read the commit messages from the same day and you see what the converter actually handed over. remove with and fix identifiers. remove unused vars. convert obj ids to names. remove empty sections. The tool produced AL that was correct and unmaintainable: object references still numeric, with blocks still hiding which record a field belongs to, dead variables abandoned years earlier that nobody had ever been forced to look at.

That is not a flaw in the tool. A converter’s job is to preserve behaviour, and it did. But its output is a translation, not a design. Taking ownership of it is a separate piece of work, and nobody quotes for it because nobody sees it in the demo.

The tests came before the behaviour, not after it

Three weeks after the conversion, a dedicated test app appears in the repository with its own manifest, alongside the main app.

The order is the point. At that moment the converted code was still a faithful translation of a system whose behaviour was documented mostly in the heads of the people using it. Any cleanup, any refactor, any attempt to make the code readable would have been a change to a system nobody could prove still worked.

So the harness went in first. Not to hit a coverage number, but to make the next three years of change provable. Everything this page claims about the system today rests on that decision, and so does every silent version upgrade since. It is the one sequence we do not negotiate on a Dynamics NAV to Business Central migration, whatever the go-live date says.

We did not go straight to SaaS, and that is what held the date

The system moved onto the current major version of Business Central the same month that version shipped, but on-premises. It stayed there five months. The move into SaaS happened the day before the next major wave was released.

That detour looks like a delay. It is the opposite. Staying on-premises separates two pieces of work that contaminate each other when they run together: does the converted code behave like the old system, and is that code even admissible in the cloud. Two questions, two answers, two points where you can step back without undoing everything.

Because the second question has a hard answer. The cloud forbids .NET interop, and a NAV system of that generation is full of it. The repository keeps the exact record of the wall: over four days the manifest target flips three times. target onprem to handle dotnet. Then revert back to use dotnet DataTable. Then target cloud, and that last commit does not only change a setting, it replaces the .NET code with AL written for the purpose.

Four days on a single point, and that point appears in no converter demo. If your customisations call .NET, the converter will hand you AL that compiles and can never be published to SaaS. You find out at deployment, not at quoting.

The monolith stayed a monolith for eighteen months

This is the fact that surprises people, and the one worth stealing.

The converted code went live as a single app. It stayed that way for a year and a half, SaaS included. Then a first module was split out, and three more followed together six months after that. The same code today is thirteen manifests.

Splitting a converted monolith early is a tempting mistake. You do not yet know where its real seams are, because the ones you can see are the ones the old system’s technical limits imposed, not the ones the business actually has. Split on those and you get thirteen apps that all have to ship together: the cost of modularity with none of its benefit.

It took eighteen months of real operation to reveal which pieces moved at their own pace. Those are the seams. Cutting there is what turns a release from “retest everything” into “ship the one piece that changed”.

What the three years actually bought

Not features. Those were already there, encoded in years of custom logic that no standard module could absorb. That is exactly why a clean reimplementation was never on the table.

Not the go-live date either. That was met in eight months.

What those three years bought is the ability to change the system. A test harness that makes a change provable. Modules that ship one at a time. A pipeline that builds and tests on every commit instead of on a developer’s machine. Object names instead of numbers, so a new developer can read a table reference and know what it points at. And, since the move into SaaS, major version upgrades that arrive on their own instead of being projects.

Three years on, it is still shipping. The most recent fix is for a notification that never fired. Ordinary maintenance, by whoever is on duty. That is what a finished migration looks like: not a go-live date, but a system a normal team can keep changing without fear.

If someone is quoting you for a conversion

Ask what happens on day two.

A quote that stops at “the code compiles as AL” has priced the cheapest, lowest-risk day of the project. The questions that decide your next three years come after it: what proves the behaviour survived, what becomes of your .NET code once it is in the cloud, when the modules get split and on what basis, and who can safely change the system once the migration team has left.

The full list of questions is in our Dynamics NAV to Business Central migration checklist. If you already have a converted codebase and nobody can tell you what state it is in, that is exactly what the Business Central clarity review is for.