ERP migration to Business Central: paths and checklist

An ERP migration to Business Central succeeds in the order data before technology: first the stocktake of customisations and the state of the data, then cleansing the master data, then the target picture in the standard, and only after that the actual migration with test runs. The path differs by source system: a NAV close to the standard is a different case from a deeply customised AX, an AS/400 or grown custom software. What all paths share is one truth: start with the technology and you carry the old mistakes across. This page orders the paths by source system, answers the data question and walks through the five steps of an orderly move.

The migration paths per source system

The right path depends less on the target system than on the starting point. The table orders the most common cases; every row leads to the full answer.

The system-independent overall path with its typical pitfalls is described in How do I switch my ERP to Business Central without carrying over the old mistakes?

The data question comes before the system question

The migration rarely fails on the tooling and regularly fails on the data. Two decisions belong before the project start: which master data comes along in which state, and what happens to the history. The approach with its step sequence is in Cleansing master data before the ERP migration, the technical side in Data migration to Business Central.

The rule of thumb from projects: cleansed master data and open items always, transaction history only after honest weighing. Legacy history is usually cheaper to keep in an archive than to drag into the new system; what matters is a conscious decision per data object.

Is the move worth it at all?

The question deserves an honest answer before the first offer, because a move that only relocates problems is not one. How to tell the difference is covered in Is switching to Business Central worth it?, and for the most common case, the stable old NAV, in It is not the version that decides the move. It is the knowledge.

The orderly path in five steps

1. Stocktake. Which customisations carry real value, which were workarounds for limits of the legacy system? What state is the data in? Days of effort, not months.
2. Cleanse the data foundation. Master data, rules, ownership, before the migration, not after. Otherwise the cleansing moves into the critical path.
3. Target picture in the standard. Check processes against the Business Central standard instead of rebuilding the legacy system. Every deviation needs a business reason.
4. Migration with test runs. At least two complete runs: the first finds the coarse errors, only the second proves the procedure.
5. Go-live against criteria. Measurable and agreed upfront, not by the calendar. After that the cloud keeps the version current automatically, and changes become routine.

Take this path and the move pays off twice: as a system change and as a clean-up of the data foundation on which AI in the ERP will carry afterwards. Steering stays on your side, with Business Central as home.

Source: Microsoft Learn: update cycles for Business Central