If you’re still running Dynamics NAV in 2026, you already know the conversation is no longer about “if”, but “when” and “how”. Mainstream support has ended. Patches, regulatory updates, and new integrations have stopped flowing your way. Every month you wait, the gap between your current setup and a modern ERP gets wider — and more expensive to bridge.
The good news : migrating to Microsoft Dynamics 365 Business Central is one of the cleanest paths forward. It keeps your data, your processes, and most of your team’s muscle memory — while finally putting you on a platform that gets updated twice a year instead of every five.
The bad news : we’ve seen too many migrations turn into 18-month nightmares because the project was framed as a “technical upgrade” instead of a business transformation. This checklist is the one we wish every IT director had on their desk before signing a single statement of work.
Why migrate now (and not next year)
Three forces converge in 2026 :
First, Microsoft has clearly closed the NAV chapter. Extended support windows for NAV 2018 and earlier versions are gone or expiring, which means no more security patches, no more tax law updates, and no path to integrate with the modern Microsoft cloud stack (Power Platform, Copilot, Fabric).
Second, your competitors are already there. Business Central now powers tens of thousands of SMBs worldwide. The companies that migrated in 2023-2024 are now reaping the productivity dividends — automated workflows, real-time dashboards, AI copilots that draft purchase orders from emails. If you’re still exporting to Excel to get a P&L, you’re losing speed.
Third, the migration window is closing faster than people think. Qualified BC partners are booked months ahead. Waiting another year doesn’t just mean another year of stagnation — it means a longer queue and higher rates.
The 7 phases of a successful NAV to BC migration
A clean migration is not a single leap. It’s a sequence of seven phases, each with its own success criteria. Skip one, and you’ll pay for it during go-live.
Phase 1 — Discovery and audit (2 to 4 weeks)
Before anyone touches code, you need a clear inventory : current NAV version, list of custom objects (modified base objects and add-ons), integrations with third-party systems, data volume by table, and a map of business processes that actually run on NAV today versus what’s drifted into Excel.
Deliverable : a written audit report and a list of “keep / redesign / drop” decisions for every customization.
Phase 2 — Target architecture (2 weeks)
Decide the deployment model (Online vs On-premises), the licensing (Essentials vs Premium, named users), and the localization. Map every NAV custom object to its BC equivalent : standard feature, AppSource extension, or custom AL extension. This is where you kill technical debt — most NAV customizations from 2010 are now standard in BC.
Deliverable : a target architecture document and a licensing quote.
Phase 3 — Data cleansing (4 to 8 weeks, in parallel)
This is the phase everyone underestimates. Duplicate vendors, customers with three versions of the same name, items with obsolete SKUs, open documents from 2014 — they all need to be cleaned in NAV before migration, not after.
Deliverable : a master data freeze with a quality report (% completeness on key fields, duplicate detection, orphan transactions).
Phase 4 — Code conversion (6 to 12 weeks)
NAV’s C/AL code does not run as-is in Business Central. It must be converted to AL extensions. A good partner uses Microsoft’s official conversion tools as a starting point, then refactors anything that was a hack into a clean extension that survives future BC updates.
Deliverable : AL extensions deployed to a sandbox environment, with a regression test plan.
Phase 5 — Data migration and parallel run (4 to 6 weeks)
Master data is migrated first, then open transactions, then closed history (or a subset). The system runs in parallel with NAV for at least one full closing cycle so finance can compare numbers.
Deliverable : reconciled balance sheets at cutoff, signed off by the CFO.
Phase 6 — User training and change management (3 to 6 weeks, overlapping)
BC’s UI is different from NAV. Power users need 1-2 days of hands-on training. End users need targeted sessions on their specific workflows. Never skip this — it’s the difference between adoption and a help desk meltdown in week one.
Deliverable : trained super-users in each department, written job aids, and a knowledge base.
Phase 7 — Go-live and stabilization (2 to 4 weeks)
Freeze NAV. Cutover during a low-activity weekend. Have the partner on-site (or on-call) for the first two weeks. Track every incident, even minor ones — patterns appear fast.
Deliverable : a stabilization report after 30 days with the list of resolved issues and remaining backlog.
The 5 traps that derail NAV to BC migrations
Trap 1 — Lifting and shifting every customization
The single biggest mistake : migrating your 2012 customizations as-is. Most of them are now standard BC features (jobs, dimensions, item attributes, document attachments). Forcing them as custom extensions means you pay for what’s free and you break with every BC update. Audit first. Cut ruthlessly.
Trap 2 — Underestimating data quality
Garbage in NAV becomes garbage in BC, only faster and more visible. Plan 20 to 30 percent of the project budget for data work. If your partner doesn’t talk about data cleansing in week one, they’re not the right partner.
Trap 3 — Treating it as an IT project
A migration is a business project with an IT component. If finance, sales, and operations leaders aren’t in the steering committee, your go-live will reveal mismatches between configured processes and how the business actually operates.
Trap 4 — Skipping the parallel run
“We’ll just switch over the weekend” is how you end up with a CFO who cannot close the month. Always run at least one full closing in parallel.
Trap 5 — Choosing on price alone
The cheapest quote is almost always the most expensive in the end. Look for partners who push back on your assumptions, ask uncomfortable questions, and show you references with similar profile and size.
Realistic cost and timeline in 2026
For a mid-sized company (50 to 250 users, one or two legal entities, moderate customization), expect :
- Timeline : 6 to 12 months end-to-end, depending on data volume and customization depth.
- Implementation cost : 80 000 to 350 000 euros (or USD equivalent), excluding licenses.
- Annual licensing : 70 to 100 euros per user per month for Essentials, 100 to 130 for Premium.
- Internal effort : plan 0.5 to 1 FTE on the customer side for the duration of the project.
If a partner quotes you 30 000 euros total for a 100-user migration, run. They either don’t understand the scope, or they’re planning to bill the rest in change requests.
How to pick the right Business Central partner
Twelve questions to ask any partner before signing :
- How many NAV to BC migrations have you delivered in the last 24 months ?
- Can I speak to two references with a profile similar to mine ?
- Who exactly will work on my project, and what is their seniority ?
- What’s your approach to handling existing customizations ?
- How do you handle data cleansing ?
- What does a typical project plan look like for a company my size ?
- How do you price : fixed fee, time and materials, or hybrid ?
- What is included in the price, and what triggers a change request ?
- How do you handle BC’s twice-yearly updates after go-live ?
- What happens if we discover scope changes mid-project ?
- Will you push back when our requests don’t make sense ?
- Show me an example of an AL extension you wrote — I want to see the code quality.
The twelfth question is the one most prospects forget. Code quality is the difference between an extension that survives five years and one that breaks at the next BC release.
The Asio Services way : ERP propre, no shortcuts
We believe most ERP problems are root cause problems, not symptom problems. A bug in a custom report is rarely about the report — it’s about a process that was never properly defined. A slow posting routine is rarely about performance — it’s about a customization that should have been standard.
That’s why we start every migration with a discovery phase that looks at processes before code. We will tell you when a customization is not worth keeping. We will tell you when your current data is too messy to migrate. We will say no when it’s the right answer.
If that’s the partner you’re looking for, we’d love to talk.
→ Book a free discovery call with Asio Services. We’ll review your current NAV setup and tell you, in plain English, what your migration would actually look like.
