The Hardest Part of a NAV-to-Business-Central Upgrade Is Deciding What NOT to Rebuild

Replacing an ageing ERP is rarely a technology problem first. It is a decision problem: every legacy customisation is either unique business logic worth preserving, or a workaround for a gap the modern platform now closes natively. The teams that move fastest are the ones who answer that question deliberately during discovery — not the ones who try to port everything and discover the answer in production.

The goal of a migration is not to move your old system. It is to retire the parts of it that should never have existed.

A Wide Version Gap Is a Different Category of Project

There is a meaningful difference between upgrading a recent ERP version and migrating one that is more than a decade behind. A short gap is largely a refactor. A long gap means table structures have moved, report engines have changed, the development language itself has been replaced, and there is no direct conversion path for the oldest objects. Treating a wide gap like a narrow one is the single most common reason these projects overrun.

The Discipline That Prevents the Worst Defects

• Assess every legacy report, integration, and customisation against one question: unique business value, or a workaround the platform now handles natively
• Rebuild only the unique logic — cleanly, in the current development language, packaged as a self-contained extension that never touches base code
• Move master and transactional data with field mappings validated before import, not discovered as gaps afterward
• Keep original report outputs as the acceptance reference — prove migrated reports against what the business actually used, not a specification