NAV to Business Central Migration: What Actually Goes Wrong

I have been called in to rescue failing Business Central implementations more times than I can count. The pattern is always the same: a company decided to migrate from Dynamics NAV, a partner started the project, and somewhere between kickoff and go-live everything broke. Data was missing, custom logic was gone, users refused to accept the new system, or the whole thing was abandoned after six months and a large invoice. This guide is not about how to do the migration right — there is a full step-by-step guide for that. This is about what specifically goes wrong, so you can recognise it before it costs you the project.

Mistake 1 — Treating It as a Technical Upgrade, Not a Business Project

The most fundamental mistake. The IT team or ERP partner frames the migration as a technical task — move the data, rewrite the custom code, swap the platform. Business users are not engaged until UAT. By that point, they are handed a system that was designed around assumptions made without them.

NAV implementations often contain business logic embedded in customisations that nobody has documented in years. Approval workflows, pricing rules, inventory posting logic, customer discount structures — all of these were built to solve a specific business problem at a specific time. When the migration team rewrites them in AL without consulting the business, they often rewrite the wrong thing. The code is technically correct but functionally wrong, and the users who discover this during UAT (or worse, after go-live) have no confidence in the system.

Mistake 2 — Migrating All Customisations Without Evaluating Them

NAV deployments accumulate customisations over years. Some are genuinely necessary; others were workarounds for limitations that Business Central has since resolved natively. A common pattern: a NAV system has 150 custom objects, and the migration partner migrates all 150 into BC as AL extensions — because it is faster and cheaper than evaluating each one.

The result is a BC system that replicates NAV's behaviour exactly, including all of its workarounds, obsolete logic, and accumulated technical debt. Users get a more expensive system that works the same way as the one they wanted to leave. They get none of BC's native improvements because they are all covered by custom code that overrides the standard behaviour.

Mistake 3 — Poor Data Migration Planning

Data migration is consistently underestimated. Teams allocate a week for what actually takes three to four weeks when done properly. The problems compound: the source data is dirtier than anyone admitted, the target table structures in BC are different from NAV in ways that require transformation logic, and the migration runs need to be tested multiple times before the final cutover.

The most damaging scenario: a single production data migration run with no rehearsal, done the night before go-live. This is how you get a go-live that is delayed by weeks, or a live system with data integrity problems that take months to clean up.

Mistake 4 — Insufficient UAT Time and Wrong Testers

User Acceptance Testing on BC migration projects is routinely compressed. The technical work took longer than planned, so UAT gets shortened from three weeks to one. The testers are often IT staff or a single "super user" rather than the actual end users who will work in the system every day.

The result is a go-live where real users encounter issues that UAT never found — not because the testers were incompetent, but because the people who actually do AP invoice entry, stock transfers, or POS end-of-day found scenarios that the UAT plan never included. These are not edge cases; they are the daily workflows that define whether the system is usable.

Mistake 5 — Underestimating C/AL to AL Complexity

Partners who have migrated a handful of small NAV systems often quote C/AL to AL rewrites as straightforward. For simple customisations, that is true. For systems with deep modifications — event subscribers, modified posting routines, custom codeunits that interact with multiple modules — the rewrite is significantly more complex than it appears.

The specific complexity that catches teams: in NAV's C/AL, modifications could directly alter base application code. In BC's AL extension model, modifications must use events and interfaces instead of directly modifying base objects. Translating complex C/AL modifications into well-designed event-driven AL code requires a developer who understands both the old pattern and the new architecture — not just one who can convert syntax.

Mistake 6 — No Parallel Running Period

Going live on BC while immediately switching off NAV is high-risk. The more financially significant the operations running through NAV (high-volume transactions, complex inventory, live integrations), the more critical it is to run both systems in parallel for at least 2–4 weeks post-go-live.

Parallel running means posting transactions in both systems and reconciling the outputs. It is operationally costly — finance teams do twice the work for a period — but it provides a real-world verification that BC is producing the same results as NAV for the same inputs. It also provides a fallback: if a critical issue is found in BC during parallel running, operations have not been disrupted.

Mistake 7 — Skipping Post-Go-Live Hypercare

The project does not end at go-live. The first 30–60 days after going live on BC are when the most issues emerge — user questions that training did not cover, edge cases in business logic that UAT missed, performance issues that only appear under real transaction volumes.

Projects where the migration partner reduces their involvement immediately after go-live consistently have worse outcomes than projects with a structured hypercare period — where the partner remains fully available for 4–6 weeks post-go-live to resolve issues within hours, not the standard support SLA of days.

The Pattern Behind All 7 Mistakes

Every one of these mistakes has the same root cause: treating a migration as a technical event rather than a business transformation. The technology — migrating data, rewriting code, configuring BC — is the easier part. The hard part is ensuring that the business still works correctly when the platform changes, and that users trust and adopt the new system.

If you are currently in a NAV-to-BC migration project and recognise 3 or more of these patterns, the project is at risk. The earlier you identify and address them, the lower the cost of course correction. Waiting until go-live to discover that data migration was under-tested or that UAT was performed by the wrong people is how the "failed ERP implementation" stories start.

If you are evaluating a migration project and want an independent assessment of your current plan and team's approach, that is exactly the kind of diagnostic engagement I run — typically a one-day review that produces a risk-ranked list of what needs attention before the project continues.