Not every AX 2012 environment takes the same route to the cloud. Your version, your X++ customizations, your ISV solutions, and the state of your data decide whether this is an upgrade or a reimplementation — and that decision changes everything about the budget and the schedule.
We analyze what you're actually running first, then tell you which Microsoft-supported path applies to your environment. You get the answer before you commit to the project.
Most migration pages write this as "AX 2012 to Dynamics 365," as though every installation follows the same path. Microsoft's supported routes differ by release, and knowing which one applies to you is the first thing worth establishing.
Every AX 2012 release is now past both mainstream and extended support, so none of them receive security updates. What varies is how you get from where you are to a current, supported platform.
Source: Microsoft product lifecycle documentation. There is no version of AX 2012 still receiving security updates. The system keeps running, but every vulnerability found since these dates remains unpatched, and that is increasingly a question your auditors, your cyber insurer and your customers' security reviews will ask about before your finance team does.
The most straightforward starting point. Microsoft's code and data upgrade tooling supports this release directly, and the data upgrade process can carry your full transactional history forward.
Also supported for direct cloud upgrade using the same Microsoft tooling. In practice R2 environments often carry more accumulated customization, which is what tends to shape the effort rather than the version itself.
Microsoft does not currently support a direct cloud upgrade from AX 2012 RTM. Reaching Dynamics 365 means either stepping through a supported release first or approaching it as a fresh implementation with data brought across.
Version isn't the only gate. Microsoft notes that AX 2012 implementations running certain deprecated features can't currently be upgraded as-is. Identifying whether any of those are in play is part of the analysis — and it's the kind of finding that's far cheaper to discover now than mid-project.
Microsoft structures the AX 2012 upgrade around three phases, and the first one exists precisely because effort can't be estimated from the outside. The analysis produces a report identifying preparation tasks, deprecated functionality, and the conflicts your developers will need to resolve.
That report is what turns a guess into a plan — which is why we run it before quoting anything.
Your AX code is exported and run through Microsoft's code upgrade tooling, which converts it to the modern format and reports every conflict a developer must resolve. Alongside it, the upgrade analysis report parses your database for deprecated features, application settings, and data volumes.
Developers resolve the flagged conflicts and rework customizations into the extension-based architecture. The data upgrade runs first in a development environment, then a sandbox — so problems surface where they can be debugged and rerun in minutes rather than during cutover.
Business processes, integrations, reports, and security are tested against the upgraded environment with your team involved. A full test cutover runs before the real one, so go-live is a repeat of something that already worked rather than a first attempt.
Two companies on AX 2012 R3 with similar user counts can run completely different projects. These are the variables that explain the gap — and each one gets a documented decision before execution starts.
Your codebase is converted to the modern format and every conflict reported. Each one is then converted, redesigned, replaced with standard functionality, or retired.
Every third-party solution is checked for a Dynamics 365 equivalent, a vendor upgrade, a replacement, or whether standard functionality now covers it.
EDI, warehouse, banking, payroll, CRM, and manufacturing interfaces are inventoried. Older point-to-point designs usually want rebuilding on modern integration patterns.
The upgrade can carry full transactional history forward. Whether it should is a separate question — data volume, quality, and cleanup materially change the effort.
Legacy report layouts and reporting approaches are catalogued, with a view to what belongs in Dynamics 365 natively and what moves to Power BI.
Approval chains and posting routines built over a decade often need redesign rather than direct conversion — and some are worth retiring outright.
Identity and access architecture changes in the cloud environment, so AX security roles and user setup are re-established rather than transferred as-is.
Legal entity count, manufacturing complexity, and multi-country operations shape scope more than most buyers expect when they start planning.
A technical upgrade carries your code and data forward. A reimplementation rebuilds on standard functionality and brings across the data you choose. Both are legitimate, and the right answer depends on what the analysis finds — not on which one a partner prefers to sell.
We don't publish a single project duration, because the honest answer is that it moves by a factor of three depending on what the analysis finds. These are the variables that decide where your project lands — and the assessment quantifies each one before we put a schedule in front of you.
A defined engagement with a defined output. We run Microsoft's analysis tooling against your environment, work through what it surfaces with your team, and hand you a document your leadership can make a decision from.
AX version, modules in use, customizations, ISV solutions, data volumes, and every live integration.
Which Microsoft-supported route applies to your environment, and any deprecated features blocking it.
A decision per customization: convert, redesign, replace with standard, or retire.
What moves, how it moves, what needs cleansing, and what's better left archived.
Every interface catalogued, with a view on what reconnects and what needs redesign.
Expected timeline, the major effort drivers behind it, and a defined implementation scope.
The output is yours either way. If you take the plan to another partner or run it internally, it still works. We'd rather earn the migration on the strength of the analysis than on a signature collected before anyone knew what was involved.
Book a 30-Min CallA short conversation covering your AX release, roughly how customized the environment is, and which integrations matter most. From there we'll outline the route available to you and what the assessment would cover.
Everything you need to know about moving from AX 2012 to Dynamics 365.
It depends on your AX version. Microsoft currently supports cloud upgrades from AX 2012 R2 and R3. AX 2012 RTM requires a different migration route. We assess your version and environment first to determine the supported path.
We analyze your X++ code, identify upgrade conflicts, and decide what should be converted, redesigned, replaced with standard functionality, or retired. Customizations are not simply carried forward unchanged.
Yes, the upgrade path can carry forward transactional history, but the right approach depends on your data quality, volume, custom tables, and business requirements. We define what should move, what needs cleansing, and what can be archived.
Not automatically. We assess each ISV solution and integration for compatibility, an available Dynamics 365 equivalent, replacement requirements, or redesign. This includes EDI, banking, warehouse, payroll, CRM, and other connected systems.
There is no single answer. An upgrade can make sense when your core processes and customizations remain relevant, while reimplementation may be better when the environment has extensive customization, outdated processes, or structural changes. We assess both options before recommending a path.
The timeline depends on your AX version, X++ customizations, ISV solutions, data, integrations, legal entities, and process complexity. We assess these factors first, then provide a realistic project scope and timeline instead of using a generic estimate.
Still have questions? Our experts are here to help.
Talk to an Expert
