Moving Off Dynamics NAV: The Upgrade Path Is Not One Hop

There is a quote on your desk and the word on it is "upgrade". You are running Dynamics NAV — 2015, 2016, 2017 or 2018 — or an early on-premises Business Central, and somebody has offered to bring you to the current release. The number is large but not absurd, and the word makes it sound like a version bump. A weekend, a backup, a new login screen, the same system with better buttons.

Microsoft's own documentation describes something structurally different, and it is public and free. Read the path before you look at the quote again.

What Microsoft's published path actually says

Microsoft's upgrade paths documentation for Business Central — a page carrying a document date of 20 February 2026 and last updated on 28 May 2026 — sets out how each old version reaches the current release. For NAV 2015 (version 8), NAV 2016 (version 9), NAV 2017 (version 10), NAV 2018 (version 11) and Business Central October 2018 (version 13), the route to Business Central 2026 release wave 1 is not a single move. It goes through version 14, then version 25, then version 28.

Read that as a project plan rather than a diagram, because that is what it is.

Each hop is a technical exercise in its own right, and each one has a data conversion attached. Your database is taken from one schema to the next, and the result has to be checked by somebody who knows what the numbers were supposed to be before the conversion started. Nobody reconciles a trial balance three times by accident. It is three rounds of testing, three rounds of reconciliation, three moments at which a figure that was right on Monday is found to be wrong on Thursday.

Which is why the quote in front of you may be entirely honest and still be incomplete. A supplier who has priced "the upgrade" as one event has either priced the whole chain without showing you the chain, or has priced one link of it. Those are very different documents and they look identical from the outside. Ask which one you are holding, in writing.

This page sits under the wider guide to the Dynamics family for UAE companies, which is where to start if you have not yet settled whether Business Central is what you want at the end of all this.

The sentence that changes what the project is

On that same page, Microsoft states the condition plainly: "This path requires you convert your application from C/AL to AL."

That sentence is worth more than every slide in the vendor deck, because "your application" does not mean the standard product. Microsoft ships the standard product. Your application is the standard product plus everything that has been done to it since installation day: the fields somebody added for a customer classification you use daily, the report finance actually closes on, the pricing logic written years ago by a developer who has since left the country, the interface to the bank, the interface to the customs broker, the thing nobody can explain that breaks if you touch it.

Converting an application from one development language to another is not an upgrade. It is a rewrite. Every one of those pieces is rebuilt, retested and re-signed, and whoever does it has first to work out what the old code was for — usually the harder half, because the requirement was never written down anywhere except in the code itself.

The size of that rewrite is a direct function of how much was customised over the years, and nobody has counted. That is not a criticism of your company. It is true of nearly every long-lived NAV estate, because customisation accretes one urgent request at a time and nobody is ever paid to inventory it. The distinction that decides the number is the old one between configuration and code somebody now owns forever, and until it has been drawn against your actual objects, every figure being quoted is a guess wearing a decimal point.

The path narrows, so the documentation has to be re-read

Here is the part that catches people who did their homework two years ago and stopped.

Microsoft states on the same page: "Starting in 2025 release wave 1 (v26), the direct upgrade from Business Central 2019 (v14) to the latest release won't be supported. The supported upgrade path will be through 2024 release wave 2 (v25)."

A route that existed when your IT manager last looked may not exist now. The published path is a living document — the one cited above was updated in May 2026 — and it is the vendor's own account of what it will and will not support. So the correct procedure is not to recall what the path was. It is to open the page on the day you decide, read it against your exact version, and put a dated copy of what it said into the file next to the quote. Two minutes, and it removes a whole category of expensive surprise.

The stepping stone is not a place to live

Now the uncomfortable part. About version 14 — the first hop in the chain above — Microsoft writes: "mainstream support for version 14 ends in October 2023, and minor updates to the version are no longer available. New customers can't use version 14 in production, but only as a path for upgrading to latest version."

Sit with what that means. The route to a supported system runs through a version that is out of mainstream support, receives no minor updates, and which Microsoft says a new customer may not run in production. It is scaffolding, not a floor.

That is fine while you are passing through it. The risk is in the stopping, and projects stall for ordinary reasons: a budget cycle, a resignation, peak season, an audit, a customisation that turns out harder than anyone thought. An estate that stalls halfway along this chain has stalled on a version with those three properties.

So put a date on it. Treat the intermediate hops as a time-boxed transit with a stated maximum duration and a named owner, agreed before the first conversion runs and written into the contract rather than the plan. A supplier who will not commit to how long you spend in transit is telling you something about the estimate. And before any of it, run the arithmetic on whether to move at all: end of support is a real push factor and it is not the same thing as a business case, which is the whole subject of what an upgrade has to be worth before it is worth doing.

What all of this actually forces you to decide

Now the part most NAV upgrade conversations never reach, and the one with money in it.

Disclosure first, because it should change how you read the next four paragraphs: we are an Odoo partner, and that is a commercial interest.

The reason companies stay with a product family through a painful transition is sunk cost, and it is normally a sound reason. You have paid for those customisations. Your people know the screens. Your processes have grown around the system's assumptions. Going elsewhere means rebuilding all of it, and rebuilding all of it is expensive, so you upgrade instead.

Except that on this particular path, you are rebuilding all of it anyway. The C/AL to AL conversion means every customisation is written again from scratch, by someone who has to rediscover what it was for. The thing the sunk-cost argument was protecting is not being preserved. It is being spent.

Once that is true, the question changes shape. It stops being "how do we upgrade" and becomes: given that every customisation is being rebuilt regardless, what should the destination be? Different question, different answer set, and it deserves a real evaluation rather than a default — which on this particular shortlist means reading Odoo set against Business Central on the structural differences rather than on feature grids.

Business Central is a strong answer to that question. It disrupts your people least, because the lineage is continuous and the concepts survive the move. It is deep in finance in a way a serious controller notices in the first hour. It arrives with a reporting stack and an identity layer that a Microsoft-standardised organisation already owns, and if your group has consolidated on Microsoft the argument is over before it starts, correctly so. The cases where it wins are structural rather than sentimental: finance as the centre of gravity, operations that are not unusual, a large population who approve and view rather than operate, and nobody internally who wants to govern a codebase. What it is not is automatic, and a destination assumed rather than chosen shows up years later in what the estate costs to keep.

Whatever you choose, put the destination's recurring cost beside the project cost while the decision is still open, because the two are usually presented months apart and only one of them repeats. Microsoft's Business Central pricing page lists Essentials at USD 80.00 per user per month paid yearly, Premium at USD 110.00 and Team Members at USD 8.00, under a footnote stating that "Prices shown are for informational purposes only and may not be reflective of actual list price due to currency, country, and regional variant factors. Your actual price will be reflected at checkout."

Treat those as the shape rather than as your invoice. A conversion is a one-off number and a subscription is a recurring one, and deciding on the first while ignoring the second is how companies end up surprised in year three. Which tier each role needs is a design question you answer once and pay for monthly.

What to establish before you commit to anything

Whatever the destination, the same four inventories decide whether the quoted number survives contact with your estate. None needs a supplier. All can be started this week.

What was actually customised, and by whom. A list of every non-standard object with a name against it and a date. Some will have been done by your original implementer, some by a second firm, some by an internal developer, some by a person nobody remembers. Provenance predicts how much documentation exists, and documentation predicts how long rediscovery takes.

Which of it is still used. The cheapest and most valuable column in the exercise. A large share of a long-lived estate is code that answered a question the business stopped asking years ago: a report for a customer you no longer supply, a workflow for an approval rule that changed years ago, an interface to a system that was decommissioned. Every item you decide not to rebuild leaves the project at zero cost, and that hour is only available before the work starts.

What the reporting layer is. Ask where the numbers your management actually reads come from. The honest answer is usually a mixture: some from the system, some from a spreadsheet that pulls from it, some from a spreadsheet that was typed. Only the first migrates. The other two are redesigned, and they are frequently the ones the board sees.

Which integrations exist. Every connection to a bank, a customs portal, a customer's portal, a warehouse system, a payroll bureau, a third party you do not control. Each is a separate negotiation on a separate calendar, and third parties do not reschedule for your project. Seams are where estates rot in general, which is the wider argument in why each additional integration keeps making things worse.

Then settle what data comes across, before anybody quotes for it. The reflex on any move is "bring everything", and against a decade of NAV documents that reflex is the largest avoidable line in the budget. Master records must move, because the system cannot transact without them. Opening balances are a position taken at one stated instant and signed by the person who owns that ledger, not a file somebody exports on a Friday afternoon. History is the part everyone asks for and almost nobody needs in the form they asked for: the auditor wants records rather than your ERP, and a retained read-only copy of the old system answers that obligation for the price of a licence, indefinitely and without a project attached. Three jobs at three prices, only one of which is a data transfer, and the reasoning is set out in what actually has to move when you change system.

Making the quote mean something

With those inventories in hand you can do the one thing that turns a proposal into a commitment: make the supplier name, in writing, every object they will convert, every object they will not, and what happens to the ones they find that were not on the list. Fix the treatment of discovered work before it is discovered, because the alternative is a variation order argued at the worst possible moment, when no other supplier could pick the work up mid-conversion.

Ask, in the same document, who owns the intermediate databases while you are in transit, who is allowed to transact on them, what the rollback is at each hop, and which named person signs that a conversion has reconciled. Those four answers separate a firm that has done this before from a firm that has read the same documentation you have. It is the same discipline as the questions worth putting to any vendor before contract, applied to a conversion instead of an implementation.

Where this leaves you

The company that comes out of this well is not the one that moved fastest. It is the one that read the vendor's own path, understood that the C/AL to AL conversion makes the word "upgrade" misleading, counted its customisations before accepting a price for rebuilding them, retired the ones nobody uses, and then chose a destination on the merits — possibly the same destination it would have chosen anyway, but chosen rather than assumed.

The company that comes out of it badly signs for one hop, discovers the chain in month three, discovers the rewrite in month five, and spends month nine on an unsupported intermediate version arguing about whether a report four people use is in scope.

The difference between those two outcomes is a fortnight of counting done before the contract rather than after it. If you want that fortnight run by somebody with no stake in which product you land on, that is how we scope work of this kind: the inventory first, the gaps priced before contract, and an exclusion list you can read.