10 Common NAV to Business Central Migration Mistakes (And How to Avoid Them in 2026)

If you’re still on Dynamics NAV, you’ve probably had that moment: someone mentions “Business Central migration,” and your brain immediately jumps to downtime, data issues, and budget surprises.

That reaction is… fair.

We’ve seen NAV migrations go brilliantly. We’ve also seen them turn into six-month detours because one “small” customization turned out to run half the warehouse.

The good news is that a mysterious technical curse doesn’t cause most NAV-to-BC failures. They usually come down to the same handful of avoidable mistakes.

This guide walks you through the big ones and what to do instead.

Why NAV Migrations Are Failing More Than Ever in 2026

If you’re running NAV and you’re feeling pressure right now, you’re not imagining it.

Support timelines are pushing more teams to act. And even if your NAV system is “working fine,” the real risk is what happens when you need security updates, compliance changes, or newer capabilities that Microsoft is shipping in Business Central.

NAV 2016 mainstream support ends in April 2026. NAV 2018 extended support ends in January 2028, which sounds far away until you remember that a complex migration can easily take 6–12 months when you include discovery, cleanup, AL work, integrations, testing, and training.

So if you haven’t started planning, you’re not “late”… but you are on the clock.

The key point: migrations don’t fail because Business Central is bad. They fail because teams underestimate what’s involved.

Let’s fix that.

The 10 Common NAV to Business Central Migration Mistakes

Mistake 1: Treating It Like a Simple Version Upgrade

This is the mindset trap.

Yes, Business Central comes from NAV. But migrating isn’t like updating Windows. The architecture and development model have moved on:

• NAV customizations were often built in C/AL.
• Business Central uses AL and extensions.
• Business Central SaaS comes with a different set of rules (no direct SQL access, stricter sandboxing).

Also, licensing catches people out. NAV commonly uses concurrent licensing. Business Central is named user licensing; finance teams often feel that difference fast.

What scope creep looks like in real life:
A company thinks they have “12 small customizations.” Then you open the objects and realize 3 of them are doing the heavy lifting for approvals, pricing logic, or inventory movements. Suddenly, you’re redesigning processes, not “migrating.”

How to avoid it:
Scope this like a new ERP implementation, even if you’re “staying in the Microsoft family.” You’ll make better decisions early (and you’ll get fewer nasty surprises later).

Mistake 2: Skipping Data Cleanup Before Migration

If we could pick one thing that causes the most go-live pain, it’s this: dirty data moving into a clean system.

NAV databases collect history. They also collect clutter:

• duplicate vendors/customers
• inactive items
• odd unit-of-measure setups
• inconsistent costing methods
• half-closed transactions nobody wants to touch

When you migrate everything “as is,” you bring every problem into Business Central, and now you’re trying to fix it while users are learning a new UI.

What a practical pre-migration data audit covers

At minimum, review:

• Customers & vendors: duplicates, missing fields, inactive records
• Items & inventory: costing consistency, obsolete SKUs, UOM mismatches
• Open transactions: unposted journals, aged POs/SOs, stale documents
• Chart of accounts: unused accounts, dimensions, old cost centers
• Audit/history needs: what must migrate for compliance vs. what can be archived

How to avoid it:
Treat cleanup as its own workstream. Do it early. And test it.

Mistake 3: Migrating Every Customization Without an Audit

NAV systems tend to grow “barnacles” over time.

Some customizations are essential. Others exist because NAV didn’t support something back then. And some are simply leftovers from a process you stopped doing years ago.

If you migrate everything without questioning it, you rebuild complexity you don’t even need.

Keep / Replace / Retire: A Simple Way to Audit Legacy NAV Work

For every customization, ask:

1. Do we still need this business process?
2. Does Business Central do this natively now?
3. If we remove it, do things get simpler or worse?

Also, check AppSource; often there’s a supported extension that replaces a custom build.

Mistake 4: Underestimating Timelines and Costs

NAV-to-BC migrations are famous for overruns for a reason: you only discover the real complexity when you look properly at:

• custom objects
• integrations
• data quality
• reporting requirements
• how users actually work (not how processes look on paper)

One decision that affects everything is how you cut over.

Phased migration vs. big-bang cutover

How to avoid it:
Choose your approach based on risk and complexity, not optimism. For many SMBs, phased is simply safer.

Mistake 5: Ignoring Integration Compatibility

This one tends to explode late, right when nobody has time.

Business Central is API-first. NAV integrations often relied on older web services, file drops, or database-level access. Those don’t map cleanly.

Your Shopify/CRM/WMS/payroll integration may still be possible, but it may need a new connector or a redesign.

How to audit integrations before you start

• List every system connected to NAV (including “one-off” scripts).
• Identify whether it uses direct DB access, web services, or API
• Check BC’s API approach for what changes
• Flag vendors who haven’t confirmed BC compatibility.
• Plan integrations as separate workstreams, not “go-live week tasks.”

Mistake 6: Picking SaaS vs. On-Prem for the Wrong Reasons

“SaaS is modern” and “on-prem feels safer” are both emotional decisions. This one should be practical.

Business Central SaaS is great for many SMBs:

• automatic updates
• Microsoft-managed infra
• Copilot/AI roadmap access

But it also means:

• no direct SQL access
• stricter extension rules
• different controls and constraints than on-prem

Mistake 7: Skipping User Training and Change Management

You can nail the tech and still fail the project if users don’t adopt it.

Business Central looks different. Navigation changes. Role centers change. And the “muscle memory” people built in NAV doesn’t transfer automatically.

How to avoid it (without making training painful):

• Pick 2–3 internal champions (finance, ops/warehouse, sales)
• Do role-based training (not one generic session for everyone).
• Give sandbox access at least 3 weeks before go-live
• Set up a simple internal FAQ and ticketing process

Mistake 8: Rushing UAT and Sandbox Testing

UAT is where “looks fine” becomes “works in real life.”

When UAT gets compressed, the bugs show up after go-live, when they’re more expensive and more stressful.

Common pain points we see when UAT is rushed:

• Inventory costing/COGS behaving differently
• Dimensions not mapping cleanly
• Approvals/workflows breaking
• Reports not matching NAV history
• Permissions that block real users

Practical UAT checklist (keep it simple, but real)

• Finance: Bank rec, VAT posting, and period close
• Warehouse/ops: Receive, pick, ship, adjustments
• Sales: Order entry, pricing, credit limits
• Integrations: End-to-end transactions across all connected systems
• Reports: Validate core reports against the NAV baseline
• Permissions: Test per role (not just admin)

Mistake 9: No Hypercare or Rollback Plan

Go-live isn’t the finish line. It’s the start of the “real world” phase.

Without hypercare, your team ends up doing two jobs at once:

1. Running the business
2. Fixing migration fallout

And if something critical breaks in the first 48 hours, you need a decision framework, not panic.

How to avoid it:

• Plan a 1–4 week hypercare window (with clear coverage)
• Define rollback triggers, decision makers, and rollback steps.
• Pick a smart go-live date.

Mistake 10: Going It Alone (or Choosing the Wrong Partner)

This is the one that quietly determines everything.

A partner who’s done “Business Central implementations” is not automatically the right person for a NAV-to-BC migration, especially if you’re customized, integration-heavy, or industry-specific.

What a real NAV-to-BC specialist does differently

• Asks for your NAV version early
• has AL developers in-house
• shows industry-relevant case studies
• audits customizations before quoting
• includes hypercare as standard

What Successful NAV Migrations Look Like

A UK-based manufacturer running NAV 2015 had 23 customisations. Instead of rebuilding everything, they audited and retired 14 that Business Central could handle natively. The remaining 9 were rebuilt as AL extensions.

Result: go-live took 18 weeks (instead of dragging on), and period-end close became noticeably faster post-migration.

Conclusion

None of these mistakes is inevitable. They’re just common, especially when teams are forced to move fast.

If you want the simplest “do this first” plan:

• Start with a system assessment
• Run a customization audit (before you commit to timelines).
• Treat data cleanup as a real workstream
• Choose phased vs. big-bang based on risk, not hope.

If 2026 deadlines are making this urgent, that’s understandable. But urgency doesn’t have to mean rushing. The fastest migrations are usually the best-planned ones.