Dynamics AX to Dynamics 365 Migration: The Decisions That Set Your Budget

Is moving from Dynamics AX to Dynamics 365 an upgrade or a re-implementation?

A Dynamics AX to Dynamics 365 migration is the move from on-premises Dynamics AX to the cloud-hosted Dynamics 365 Finance and Operations platform. For most estates it is a re-implementation with data migration, not a version upgrade. Microsoft supports an in-place data upgrade only from AX 2012 R2 and AX 2012 R3.

That distinction is not semantics. It decides whether you budget for a technical project or a business one.

A Dynamics AX to Dynamics 365 Finance migration follows the same path as a full Supply Chain footprint. Your AX version sets that path, not your module scope.

Microsoft is unusually direct about this in its own documentation. It calls the upgrade tooling a framework rather than a complete solution. The reason: an AX 2012 database and its metadata hold too many variables for the process to handle every case. Read that next to any partner promise of a smooth transition and you have the honest shape of the work.

So the question is not whether to migrate from Dynamics AX to Dynamics 365 Finance and Operations. Your search already answered that. It is which of four paths applies to your version, and what each one costs.

Where each Dynamics AX version stands today

All of them are out of support. None receives security patches, hotfixes, or the regulatory and tax updates that finance teams depend on every year. What separates them is whether Microsoft will carry your data across automatically.

Dates come from the Microsoft Lifecycle pages for Dynamics AX 2009, Dynamics AX 2012 and Dynamics AX 2012 R3, checked in August 2026. Several widely read guides still print these dates in the future tense. One publishes a version that does not exist. Check any table you are handed against Microsoft directly.

Two conditions block the upgrade path entirely, whatever your version. Microsoft states that systems using virtual companies or data partitions cannot currently be upgraded. Both are common in multi-entity manufacturers and shared-service finance functions. Find out which applies to you before the business case reaches the board.

The Dynamics AX to Dynamics 365 migration process, phase by phase

Five phases, and the first one decides the shape of the other four. Most programs that slip do so because they compressed the assessment to reach a number faster.

1. Assessment. Run the code analysis, profile the data volumes, and inventory every integration and ISV. The output is a scoped path, not a proposal.
2. Build and configure. Set up the Dynamics 365 environments, configure the standard processes, and rebuild only the customizations that survived triage.
3. Data migration and mock cutovers. Move master data first. Then run the full load at least twice under production conditions.
4. Test. Functional test pass against the rebuilt processes, then user acceptance testing with the people who will use it daily.
5. Cutover and go-live. Freeze, final load, reconcile, open.

What the code analysis actually tells you

The useful output is not a count of your customizations. It is a count of how many objects were overlayered, and how many of those now have a native equivalent in Dynamics 365.

Those two numbers drive the code budget more reliably than anything else in the assessment. Take a finance team with 400 modifications, where 300 are workarounds for gaps Microsoft closed in 2019. That team has a smaller program than one with 80 modifications that are all genuinely its own.

Mock cutovers set your downtime figure

Run the data upgrade at least twice before go-live. The first run finds the breakages. The second gives you a timing you can defend to the business.

Anyone quoting a cutover window before a mock run has happened is estimating from a template. The window is a function of database size and data load runtime. Neither is knowable in advance.

Adoption starts earlier than your plan assumes

Your users have been in the same AX screens for a decade. The Dynamics 365 interface, the workflows and the role-based security model are all different. Role-based security in particular surprises finance teams who had informal access in AX.

Name the training owner during assessment. Change management is the workstream that gets cut when the timeline tightens, and it decides whether month-end works in week three.

What happens to your X++ customizations

They do not come across. In AX 2012 you modified the product by layering your code on top of the base application. Dynamics 365 does not allow that. Microsoft's position is explicit: extensibility is the only customization framework in Finance, Supply Chain and Commerce, and overlayering is not supported.

This is the largest cost driver on most programs, and the one competitor guides tend to cover in a sentence. Every overlayered object becomes a decision rather than a port.

Three buckets handle almost all of it:

• Retire. The modification exists because AX could not do something in 2014. Dynamics 365 does it now. This is usually the biggest bucket, and nobody expects it to be.
• Rebuild as an extension. The logic is genuinely yours and gives you an edge. Rebuild it against the extension model instead of translating old code.
• Re-examine. Nobody can explain why the modification exists. Find the process owner before you spend money either way.

Getting this triage right is ordinary application modernization services work. Do it before the implementation partner scopes the build, not during it.

Deciding what data to move

Move master data, open transactions and opening balances. Leave historical transactions behind unless a live process reads them, and put that history in a read-only archive. This decision drives your cutover window and your running cost more than any other. Almost every guide on the topic names it as a consideration without deciding it.

The economics sit in Microsoft's own documentation. Part of the Dynamics 365 subscription cost is based on database size, and a smaller database produces a faster upgrade go-live. So a Dynamics AX to Dynamics 365 data migration is a cost decision and a downtime decision at once.

The attachment row catches people. Microsoft is clear that attachments survive the upgrade only if they were migrated into the AX 2012 database first. Attachments sitting on a file share do not come across.

Then the question a CFO asks and no ranking guide answers. Where does the statutory record live once AX is switched off? Not in the new ERP. Build a read-only archive holding the AX transactional record for your retention period, with documented access for audit and tax.

That archive is a funded deliverable with an owner. Treat it as data platform modernization work, or it gets discovered during the first audit after go-live.

Scale is rarely the blocker when scope is decided deliberately. On an insurance data platform move off Oracle to Snowflake, our team migrated 4,500 tables and more than 12 billion rows. Nightly loads reached a 99.9% success rate. That was a data platform migration, not an ERP one, and the transferable lesson holds: estates move cleanly when somebody decided what not to bring.

Integrations, ISVs and reports: the three discovered late

Every connection into AX has to be rebuilt against a different API surface. Count your integrations early, because that number predicts your timeline better than your user count does.

ISVs carry the risk people miss. An AX add-on with no Dynamics 365 equivalent is a rebuild, a replacement, or a reason to change the process it supports. Re-licensing and certification against the current release sit outside your control. That makes them a schedule risk, not a line item you can negotiate down.

Reports do not survive either. AX SSRS reports and Management Reporter content need rebuilding. This is where a Power BI and Power Platform reporting layer legitimately enters the conversation. Treat it as a rebuild you are funding, not a benefit you are receiving.

What it costs and how long it takes

The public numbers disagree by roughly three times, and none of them explains why. Here is what four widely read partner guides published as of August 2026.

Six drivers explain almost the entire spread in any AX migration to Dynamics 365.

1. Whether your version supports an in-place data upgrade, or you are re-implementing.
2. Overlayered object count, and how many have a native replacement.
3. Integration count.
4. ISV replacement, including add-ons with no equivalent.
5. History scope, which sets database size and the cutover window.
6. Internal backfill for the people you pull onto the program.

An estimate produced without a code analysis, a data volume profile and an integration inventory is a guess with a decimal point. Ask for those three before you accept any number, including ours. If you have run a large ERP move before, the cost shape will look familiar. On a SAP ECC to S/4HANA migration, custom code remediation drives the budget the same way.

What changes after go-live

You stop owning upgrades and start owning a release cadence. That beats eight years of deferred AX updates. It is also an operating change that most guides sell as a pure benefit.

Microsoft's One Version service updates policy sets the terms. Four service updates a year, released in February, April, July and October. You can pause one consecutive update, not three. Your environment has to stay within one version of the current release. And you get seven calendar days to validate in a sandbox before production updates automatically.

For a team that has not taken an AX update since 2019, that is new work. It needs a regression suite, a named owner, and a line in next year's budget. Microsoft ships the Regression Suite Automation Tool for exactly this. Teams that set it up during the program, rather than after go-live, stop noticing release waves.

Azure elasticity, Power Platform and Copilot are real gains, and they arrive on the same terms. Each is a capability you now have to run. Where the underlying infrastructure question matters, the same reasoning applies to moving on-premises workloads to Azure more broadly.

Where this fails

The case to migrate Dynamics AX to Dynamics 365 is not universal. Three situations make starting this year the wrong call, and not one ranking guide on this topic names any of them.

You are mid-carve-out, mid-acquisition, or a business unit is scheduled for divestment. Your legal entity structure is about to change. Configuring an ERP against a structure that will not exist in eighteen months means paying to do it twice. Stabilize AX, isolate it, and start on a dated plan after the transaction closes.

A plant-floor or MES integration has no Dynamics 365 equivalent and no rebuild budget. The ERP is not your constraint here, the integration is. Sequence the integration replacement first. A go-live date set before that work is scoped is not a date, it is a hope.

Your IT function cannot absorb four mandatory service updates a year on top of the program. Going live and then failing the update cadence rebuilds the same technical debt in a more expensive place. Fix the capacity question first, even if that means a smaller first phase.

One more, and it is the advice we give most often on ERP moves. Do not let the implementation partner scope the build before an independent code analysis exists. The party writing the estimate and the party delivering against it should not be the same firm in the same week.

Get a costed path for your AX version

Most Dynamics AX migration estimates are wrong because they were built before anyone read the code. Entrans runs a migration readiness assessment. You get three things a board can act on. A code analysis showing which objects were overlayered and which now have a native Dynamics 365 equivalent. A data scope decision with the archive plan attached. An integration and ISV inventory with the schedule risks named. That is a costed path for your specific AX version instead of a range copied from a blog. Entrans has transformed 200+ enterprises across US, UK, UAE and India. Start with Entrans digital engineering services.