What AX 2012 Estates Get Wrong About the Move to D365

The easy AX 2012 migrations happened years ago. The estates still running today are the complicated ones: heavily customised, deeply embedded, and owned by businesses that have quite reasonably concluded the move is a big job. It is. But most of what goes wrong in these programmes goes wrong in the framing, before any migration tool is run.

Having now seen this migration from several angles, including behind other consultancies, these are the mistakes that repeat.

Treating it as an upgrade

AX 2012 to Dynamics 365 Finance and Operations is a re-platform, not a service pack. The customisation model changed from overlayering to extensions, the update model changed to a continuous cadence, and the hosting changed to cloud. Businesses that frame the project as "the upgrade" plan it too small, staff it too thin and are surprised by the extension rework. Businesses that frame it as a re-platform with a well-worn path plan it correctly, and are then pleasantly surprised by how much the tooling helps.

Carrying everything across

When the decision defaults to "keep it working like today", every customisation comes along: the useful ones, the abandoned ones, and the ones that exist because of how a manager in 2013 liked a screen laid out. We have seen the carry-everything path fail outright, and the failure mode is predictable. Nobody reviews anything, so the new system starts life carrying a decade of undocumented decisions, and every future Microsoft update has to be tested against all of it.

The alternative costs more in planning and less in everything else: review every customisation and score it honestly. Still used. Not used. Better served somewhere else. On the estates we have assessed, all three buckets are always well populated, and the "not used" bucket is always bigger than the client expected.

Rebuilding everything in F&O

The third mistake is subtler. AX estates accumulated functions that never belonged in an ERP, because for years AX was the only system with development budget. After-sales service, sales pipeline, quotation tools, HR records. The default instinct is to rebuild all of it inside Finance and Operations, which is the most expensive place to build and the most expensive place to maintain.

Most of it belongs elsewhere. Customer-facing processes fit Customer Engagement. Departmental workflows fit the Power Platform, where building is cheaper than X++ and survives updates better. Statutory reporting that needed custom code in the AX era is often covered by localisation packages now. The migration is the one moment the business gets to put each function where it should live, and the licensing usually lands in a similar place to where it started.

Ignoring what the tooling is telling you

Microsoft's upgrade tooling is genuinely useful and mostly used too late. Upgrade Analyzer will tell you, before planning finishes, what will not carry across and what data should be cleaned first. The code upgrade estimation service will convert the model store and hand back a sized backlog of X++ work. An estimate produced without these is a guess, and programmes priced on guesses reliably discover the truth mid-flight, when it is most expensive.

We have written up the full decision path, including the tooling and the data strategy, in our AX 2012 to D365 migration guide. If your estate is still on AX 2012, the honest first step is not a contract. It is an assessment that tells you which of the three paths fits, with evidence attached.

Marcel Rizzolo is Director of Coder Trove. Our Dynamics 365 practice has delivered AX-to-D365 migrations for multinational organisations, directly and behind consulting partners.