The four most common AX 2012 to D365 migration mistakes are treating the move as an upgrade, carrying every customisation across, rebuilding everything inside Finance and Operations, and using Microsoft's upgrade tooling too late. All four are decisions of framing, made before any migration tool runs.
Microsoft ended extended support for AX 2012 R3 in January 2023, and the easy migrations happened years ago. The estates still running are the complicated ones: heavily customised, deeply embedded, and owned by businesses that reasonably see the move as a big job. It is, and we have seen the same mistakes repeat, including on programmes we joined behind other consultancies.
AX 2012 to Dynamics 365 Finance and Operations is a re-platform. The customisation model changed from overlayering to extensions, the update model changed to a continuous cadence (see managing One Version updates), and the hosting moved to the 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 plan it correctly, and find the tooling helps more than expected.
When the decision defaults to "keep it working like today", every customisation comes along: the useful, the abandoned, and the ones that exist because a manager in 2013 liked a screen laid out that way. We have seen the carry-everything path fail outright. 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. 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.
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 instinct is to rebuild all of it in Finance and Operations, the most expensive place to build and 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. Localisation packages now cover much of the statutory reporting that needed custom code in the AX era. The migration is the moment to put each function where it belongs, and licensing usually lands close to where it started.
Microsoft's upgrade tooling is useful and usually run 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 find the real size mid-flight, when change is most expensive.
Our AX 2012 to D365 migration guide covers the tooling, the data strategy and the three migration paths: reimplement on standard, carry everything across, or carry across only the customisations still in use. If your estate is still on AX 2012, start with an assessment that shows which of those paths fits, with evidence attached. Our Dynamics 365 practice runs that assessment, directly or behind consulting partners.
Microsoft ended extended support for AX 2012 R3 in January 2023. The software still runs, but it receives no security patches or regulatory updates.
A single-entity migration with disciplined scope typically runs two to four quarters. Multinational estates with several legal entities usually take twelve months or more; see how long a Dynamics 365 implementation takes.
Running Upgrade Analyzer, inventorying and ranking the X++ customisations by usage, profiling data quality in the tables that will migrate, and mapping the integrations that touch AX.
Marcel Rizzolo is Director of Coder Trove.