AX 2009, AX 2012, and older Axapta installations are still running real businesses. Moving off them is a genuine project, not an upgrade wizard. Here is what is actually involved.
Almost nobody migrates off AX because they want new features. They move because the support position became untenable, because the server hosting it is aging out, because the last person who understood the customizations retired, or because an auditor started asking questions that an unsupported ERP makes hard to answer.
Microsoft's support lifecycle for the AX generation has run its course, and the specific dates vary by version and release. Microsoft's lifecycle documentation is the authoritative source for where your particular installation stands, and it is worth checking before you plan a budget cycle around it.
The practical consequence is that AX becomes a business risk rather than a business tool. It still works, right up until the day it does not, and by then the timeline is not yours to choose.
The single most expensive misconception about this migration is that it is a version upgrade. It is not. The data model changed, the customization model changed fundamentally, and the operating model around environments and releases changed completely.
In AX, customizations were commonly built by over-layering: modifying Microsoft's own code in place. In D365 F&O that approach is gone, replaced by an extension model where your code attaches to Microsoft's rather than altering it. Every over-layered customization you carry has to be reassessed, and a meaningful share of them turn out to be unnecessary because standard functionality has since caught up.
That reassessment is the most valuable part of the project and the part most often skipped. Every customization you retire is code you never have to test against another Microsoft release.
Cataloguing customizations, integrations, reports, and the processes that depend on them. Establishing what must move, what can be replaced by standard functionality, and what should simply be retired.
Rebuilding what survives assessment in the extension model. This is development work, not conversion, and estimating it honestly is the difference between a project that lands and one that does not.
Master data, open transactions, and the historical record. Deciding what genuinely needs to come across is a business decision with a large cost attached, and it deserves more discussion than it usually gets.
EDI connections, carrier and ecommerce integrations, payment processing, and warehouse systems all need to be re-established against new interfaces.
LCS, Azure DevOps pipelines, and the sandbox topology. Cloud ERP has a release cadence, and you need a process for absorbing it.
Conference room pilots, user acceptance testing, and the cutover plan itself, including what happens if a step fails at two in the morning.
Three factors dominate, and headcount is not among them. The first is customization depth: a lightly customized AX 2012 installation is a fundamentally different project from one where core posting logic was modified a decade ago by someone who left no documentation.
The second is integration count. Every external system connected to your ERP is a small project of its own, with its own testing and its own failure modes. Distributors tend to be integration-heavy, which is why these projects run longer for them than for a comparably sized manufacturer.
The third is data history. Bringing ten years of transactional history across is possible, expensive, and frequently unnecessary. Most businesses need far less than they initially believe, and the conversation is worth having early because it moves the number substantially.
Treating it as a technical exercise. The migration is an opportunity to fix processes that were worked around for a decade, and teams that ignore that opportunity rebuild their old problems in a new system.
Underestimating the customization rework. Assessment happens too fast, everything is assumed to be portable, and the true scope surfaces halfway through the build when the budget is already committed.
Skipping the conference room pilot. Running your own transactions through the configured system, with your own people, is how you find the gaps while it is still cheap to fix them.
Ending the engagement at go-live. The weeks immediately after cutover are when performance problems, process gaps, and training shortfalls surface. A project that disbands the day the system goes live is a project that leaves its hardest problems to the client.
Tell us what you're working through. We reply within one business day, and there's no obligation — we're happy to give initial guidance even if we're not ultimately the right fit.
Prefer to talk it through? Call 720-219-6740