Migration

NAV/Navision to Business Central migration guide

How to assess upgrade vs reimplementation, manage extensions, and run a controlled cutover from NAV to Business Central.

NAV to Business Central decisions often get framed as a technical exercise. In practice, they are business design decisions disguised as an upgrade conversation.

If the legacy NAV estate carries years of customisations, reporting workarounds, and manual controls, the wrong migration path can leave the business paying modern software costs for yesterday’s operating model.

The useful question is not only whether you can upgrade. It is whether you should preserve the current design, reshape it, or reset parts of it while moving to Business Central.

What to assess before choosing upgrade or reimplementation

• Extension footprint: how many custom objects, reports, and integrations are genuinely still needed?
• Process drift: how far has the live system moved from the original intended process design?
• Reporting debt: are close, stock, margin, or project reports being held together outside the ERP?
• Data quality: would a direct migration simply carry broken structures and duplicate records into the new platform?
• Business change appetite: is leadership expecting process redesign or only technical currency?

Signals that a reimplementation may be the better path

• Teams cannot explain why several customisations exist or who still owns them.
• Critical processes such as approvals, inventory control, or customer pricing are partly outside the system.
• The business wants a new reporting model, stronger controls, or a cleaner CRM and warehouse integration approach.
• Data structures are inconsistent enough that migration and testing would be painful either way.

What a good migration plan looks like

• Run discovery with business leads and technical leads together so the future design is not biased by only one lens.
• Build a conversion register covering extensions, reports, interfaces, user groups, and manual controls.
• Prove the cutover sequence in rehearsals with real timings, business sign-offs, and rollback decisions.
• Protect the first month-end close and first full operating week as hard go-live criteria rather than afterthoughts.

FAQ

• Can we phase the migration? Yes, but only if the business can tolerate temporary process splits and clear ownership exists across legacy and new environments.
• Is a technical upgrade always cheaper? Not necessarily. Preserving poor design can create more cost later in support, reporting, and improvement work.
• Should we clean data before or during migration? Before and during. Early ownership matters, but real issues only fully emerge during rehearsal cycles.