Dynamics AX to Business Central: upgrade, migrate or replace?

There is no one-to-one move from Dynamics AX to Business Central. AX is the larger, more deeply customised system; BC is a different product. Legacy AX systems carry years of custom development in X++, often processes that were never documented, and that logic does not simply carry over into Business Central. For every grown modification there are exactly three honest routes, and you should choose deliberately: keep it, because the process genuinely sets you apart from competitors; rebuild it cleanly as an AL extension, upgradeable instead of anchored in the core; or return it to the standard, because the special logic was a workaround. This is why „replace“ is usually more honest than „migrate“ with AX. The honest question is not how you migrate, but what you deliberately carry along and what you leave behind. That is where control on your side begins.

Why does “upgrading” mislead with AX?

Legacy AX systems hold years of custom development in X++, often processes that were never documented. This logic does not automatically continue in Business Central. For every grown customisation there are exactly three honest paths, and you should choose them deliberately, not leave them to chance.

• Keep it, because the process truly sets you apart from the competition.
• Rebuild it cleanly as an AL extension, upgradeable instead of anchored in the core.
• Return it to the Business Central standard, because the special logic was a workaround.

Source: Microsoft Learn: Development in AL

With AX, "replace" is usually more honest than "migrate". You rebuild the data foundation cleanly, and what comes along is your decision rather than an automatism. That sounds like more effort and in total is often less, because every special path carried along blindly costs three times over: once in the rebuild, once in testing, and then continuously in operation.

Data migration: what belongs live, and what in the archive?

The critical block is and remains the data migration: open items, history, master data. Not everything has to go into the live system. Much of it belongs in an archive you read from when needed, without burdening the new system with legacy weight.

• Open items and ongoing transactions go into the live system cleanly mapped.
• Historical postings and closed cases move into an audit-proof archive.
• Master data is cleaned up before transfer, not carried over one to one.

That separation lowers effort and risk at the same time, because archive data needs no ongoing upkeep and does not have to fit the structure of the target system. For loading the productive data, Business Central brings its own tools that can be run repeatedly, which is what makes repeated trial runs practical at all.

Source: Microsoft Learn: Set up company configuration packages

How do you test the scaling before you start?

Very large AX installations need an honest BC suitability check before the start. Licence and scaling questions also decide whether Business Central is the right target or whether parts belong in a different structure. This assessment belongs at the beginning, not in the middle of the project.

Source: Microsoft Learn: Licensing in Dynamics 365 Business Central

Concretely it comes down to three quantities: the number and type of users, the volume of the transaction-heavy tables, and the depth of the integrations. All three can be established up front, and they lead either to a clear commitment or to a deliberate split across several environments. Both are a usable result; only the untested assumption is not.

So talk to us before you settle on a route: we assess your AX processes honestly and show you what sensibly lives on in Business Central as home.