Why the move off NAV gets harder every year you wait — and how to run it without blindsiding the people who depend on the system.
For thousands of distributors and manufacturers, Dynamics NAV still runs the business. It posts invoices, tracks inventory, and closes the books each month without much drama. That reliability is exactly why a migration keeps sliding to next quarter; nobody schedules surgery for a system that still works.
The strain has started showing in less convenient places, though. Consultants who know the platform are getting harder to find. The people who use it daily have quietly built workarounds for the things it cannot do. And mainstream support ended years ago, so the software itself sits frozen while everything around it keeps moving. None of this announces itself; it accumulates, and each year on NAV costs a little more than the one before.
What follows is a practical look at where a NAV to Business Central migration gets hard in 2026, and how to handle each part without losing sight of the people who rely on the system day to day.
Key Notes For Migrating From NAV to Business Central in 2026
Every version of Microsoft Dynamics NAV has aged out of mainstream support, which means no new features and, more to the point, no security patches. Meanwhile the bench of consultants who still know C/AL and the older NAV architecture keeps thinning. When the one developer who understands your fifteen-year-old customization finally retires, most of that knowledge walks out the door with them.
The economics nudge in the same direction. Microsoft's current incentive, Bridge to the Cloud 3, runs through the end of 2027 and trims the cost of Business Central online licenses for companies coming off on-premises systems. Worth knowing, though it is not the thing that should drive the decision. The pressure that matters more is operational: wait long enough, and the timing stops being yours to choose.
Ask a NAV administrator what keeps them up before a migration, and the answer is almost always the customizations. Years of C/AL code, custom reports, and workflow tweaks the business now leans on, often with no one left who remembers why half of them were built.
This is where expectations and reality part ways. Most teams assume their code will move across intact, and it will not, because Business Central online does not run C/AL at all. Customizations get rebuilt as AL extensions, which keep your custom logic separate from the core. That separation is what lets the platform update itself twice a year without trampling your changes, a real improvement on the old upgrade slog, even if it does rule out any kind of straight code transfer.
So the work starts with a full customization inventory, taken before anyone touches the migration itself. Every modification gets sorted into one of three buckets: rebuild it as an extension, swap it for a standard feature that now does the same job, or drop it because the business has moved on. A surprising number land in that last bucket. They were written years ago to fill a gap that Business Central has since closed on its own.
On the mechanical side, Microsoft's cloud migration tool does its job well. It copies your NAV tables into Business Central online one at a time, and your on-premises system stays the source of truth right up until cutover, so nobody on the floor notices the data moving underneath them.
The judgment calls are harder than the mechanics. Take history: how many years do you really need to carry forward? Hauling a decade of detail across because it feels safer just bloats your storage and drags out the timeline, when three to five years usually covers what operations and auditors will ask for. Then there are the small landmines, like a company name with a trailing space or an odd character that quietly derails replication. A diagnostic run before the real thing catches most of them, which is why skipping it tends to be a false economy.
Integrations are the part nobody volunteers to own, because one small change can ripple outward in ways that are genuinely hard to predict. Warehouse systems, EDI feeds, e-commerce platforms, shipping tools, the odd connector somebody wrote years ago and never documented: all of it has to be mapped up front, while there is still room to plan around whatever you find.
The platform itself was built for modern, API-based integration, and it connects natively with Power BI, Excel, Teams, and Power Automate, so a good chunk of the Microsoft stack comes along with no middleware at all. The real work is sorting each connection into move-as-is, rebuild, or retire. To the plant manager waiting on a nightly feed to their suppliers, none of that architecture matters; what matters is that the feed is there when they log in Monday morning.
This is the piece that gets underestimated, and it is the piece your end users will feel the most. Business Central simply looks and behaves differently from NAV. The navigation has moved around, the role-based home pages are new, and the muscle memory your team spent a decade building no longer lands quite where their fingers expect it to.
None of it is hard to pick up, but it does have to be picked up, and that takes time nobody likes to budget for. A warehouse clerk who used to post a transaction without looking will fumble for a week or two, and that slowdown is completely normal. The teams that come through this cleanly are the ones that planned for the dip. They train on real tasks instead of canned demos, lean on a few power users as in-house champions, and put the new system in front of those people early, tested against the work they do every day. That is usually where a project is quietly won or lost. You can run a technically flawless migration and still have it land badly if the people living in the system feel ambushed on go-live morning.
The migrations that go well are almost never rip-and-replace events; they are phased transitions with checkpoints you can see coming. Most run somewhere between three and nine months, and the range is that wide for a reason. A lean environment with a handful of integrations moves quickly, while a heavily customized one with a dozen moving parts will take its time, and there is little upside in pretending otherwise.
A sound sequence moves from discovery and assessment into planning, then into development and testing, then a controlled go-live, and finally a stabilization stretch that too many teams treat as optional. Skipping it is a mistake. The first month-end close on a new system is when the awkward questions surface, and having someone who knows your setup on hand through that window is what turns a rough week into an ordinary one. It is also why plenty of organizations roll straight into ongoing managed support; for them, go-live is less a finish line than the point where the work changes character.
If you are still on NAV, none of this means you have to move next month. It means the move tends to go better when you choose the timing yourself, scope it with clear eyes, and walk in knowing where the complexity lives, which customizations still earn their keep, and how ready your people really are. With 35-plus years and more than 1,250 Microsoft Dynamics implementations behind it, Western Computer has run this play across exactly the distribution and manufacturing environments described here.
A structured NAV to Business Central readiness assessment is how you trade guesswork for a plan, and it is what lets the move to Dynamics 365 Business Central happen on a schedule you set yourself.