AX 2012 to Dynamics 365: what upgrades and what gets rebuilt

Dynamics AX 2012 R3 left Microsoft’s extended support on 10 January 2023. AX 2009 SP1, AX 2012 and AX 2012 R2 left it earlier, on 12 April 2022. Since those dates there have been no security hotfixes, and even during extended support Microsoft provided neither nonsecurity hotfixes nor regulatory updates. An AX 2012 system still in production today is an ERP with no security patches and no help with tax or regulatory change.

Microsoft does provide an AX 2012 to Dynamics 365 upgrade path into finance and operations, and it is genuinely useful: it can bring your full transactional history across. But it has hard limits on who can use it, and Microsoft itself describes the tooling as a framework rather than a complete solution. This article sets out what carries across, what gets rebuilt, and when it is cheaper to start again.

Where AX stands today

The regulatory point is the one that bites first. Tax rules, e-invoicing mandates and reporting formats keep changing, and every one of those changes is now yours to build and maintain on a platform nobody is patching. Most AX estates we see have absorbed this quietly for a year or two, and the cost is spread across so many small changes that nobody has added it up.

One R3 client on extended support had to build an e-invoicing format change in-house, because no vendor update was coming. It took three sprints of a developer’s time and never appeared on any project plan, because it was filed as a fix rather than as the cost of staying on an unsupported platform. That is what this looks like in a budget. Not a line item, a series of small emergencies.

What the upgrade path actually is

Microsoft’s upgrade guidance sets three conditions before anything else.

You must be on AX 2012 R2 or R3. Those are the only supported starting points, and each must be updated to its latest cumulative update first. AX 2009 is not a supported upgrade source. An AX 2009 estate is a migration, not an upgrade.

You cannot be using virtual companies or data partitions. Upgrade is not possible from systems that use either. If your AX 2012 design relied on them, the upgrade path is closed, however current your version.

The database has requirements of its own. The AX 2012 database collation must be SQL_Latin1_General_CP1_CI_AS. Microsoft strongly recommends running the Upgrade analyzer and resolving what it finds before attempting the data upgrade.

If those conditions are met, the process runs in three phases, Analyze, Execute and Validate, built on two sets of tools: one to bring custom code forward, and a data upgrade that brings the database across with its full transactional history. That last part is the main reason to upgrade rather than reimplement.

Microsoft is candid about the effort. Its guidance says AX 2012 upgrades are complex, that nobody should assume the process runs end to end without data clean-up, tuning and customisation, and that the tools are a framework rather than a complete solution. A single data upgrade run can take several hours, and in larger sandbox environments each cycle of debugging, fixing and rerunning takes several more. Plan for many runs, not one: in our experience a clean run at the first attempt is rare, and two or three runs before one comes through clean is the normal shape rather than the exception.

Two practical levers reduce both time and cost. Data cleanup comes first: the tooling identifies data you can remove without losing functionality, and a smaller database shortens every upgrade run and reduces the storage component of the subscription cost. And for qualified on-premises customers, Microsoft’s AIM (Accelerate, Innovate, Move) offering provides migration advisors and an assessment.

What carries across, and what gets rebuilt

The upgrade moves data and brings code forward. It does not bring the architecture of an on-premises system across unchanged, and four areas are effectively rebuilt.

Customisations become extensions. Microsoft’s guidance is that overlayering increases the cost of upgrading, while extensions reduce it and let Microsoft patch and upgrade the cloud service without affecting them. AX 2012 code that modified standard objects directly is the expensive part of every upgrade estimate, and moving it to extensions is where most of the code effort goes. The AX 2012 XPP events your code may already use remain available, which helps.

In the upgrades we have run it is not merely the expensive part. It is the single biggest driver of the estimate, and it is not close. It is also the part most often discovered late. On one R3 estate a customisation nobody remembered had patched a core posting routine directly, and it surfaced as an object conflict three weeks into the Execute phase, long after the timeline had been agreed.

Microsoft’s sequence puts that discovery earlier. The code upgrade estimation tools belong in the Analyze phase: you export the AX 2012 model store, the Code upgrade tool converts it and returns an upgraded version plus a report of the conflicts a developer still has to resolve. That report is what an estimate should be built on, and running it in week one rather than week three is the difference between a plan and a hope.

Integrations are redesigned. Finance and operations offers a defined set of integration patterns: OData, the batch data API, recurring integrations, the data management package REST API, custom services and Power Platform integration. Each AX interface should be mapped to one of these deliberately rather than ported. We would treat each interface as a design decision, and choosing an integration pattern deliberately covers how.

Operations move to a shared model. On premises, your team owned the servers. In the cloud, Microsoft runs the infrastructure, security and the application platform, and its service description is specific about what stays with you: managing application updates and validating extensions, managing ISV solutions and third-party integrations, and monitoring and managing non-production deployments. The skills and the budget move with that line. A team used to patching servers has to become a team that tests releases.

Environments follow the cloud offer. Production and one Tier 2 acceptance environment are included, performance testing needs an add-on environment, and production is only provisioned after a Go-live Readiness Review held no later than four weeks before go-live.

Upgrade or reimplement?

The upgrade path is worth taking when the AX processes are sound and the history matters. It is the wrong choice more often than people expect.

Our position: decide the route before you estimate the upgrade

In our view the most expensive mistake in an AX 2012 to Dynamics 365 programme is estimating the upgrade before deciding whether to upgrade at all. Once a team has priced the upgrade, every blocker that turns up afterwards gets treated as scope creep, when it is new information that should have changed the plan. A data partition, or a customisation that cannot become an extension, becomes a change request instead of a routing decision.

So the order we would follow is: run the Upgrade analyzer, check the hard blockers, look honestly at how much of the customisation still earns its keep, and only then choose between upgrade and reimplementation. For small estates, include the question of whether finance and operations is the right destination at all; Business Central vs Finance and Operations covers the published limits that decide it.

Where to start

1. Confirm your version and cumulative update, and whether virtual companies or data partitions are in use.
2. Run the Upgrade analyzer against the AX 2012 database, and do the data cleanup it recommends. It reports deprecated features, application and database settings, and the space savings that shorten every later run.
3. Run the code upgrade estimate in the same week. The conflicts report is what a credible timeline is built on, and it is the one that finds the customisation nobody remembers.
4. Inventory customisations and interfaces, and mark which still earn their keep.
5. Choose the route, upgrade or reimplement, before anyone produces a delivery estimate.

Our fixed-fee Dynamics migration readiness assessment covers exactly this ground: from $3,500, in two weeks, with a current-state review, a data quality assessment, a Dynamics 365 fit and gap analysis and a costed plan. Veratas then delivers the finance and operations upgrade or implementation that follows.

If you are still on AX and not sure which route is open to you, talk to our team. The blockers are usually knowable in an afternoon.

Frequently asked questions

Is Dynamics AX 2012 still supported? No. AX 2012 R3 extended support ended on 10 January 2023, and AX 2009 SP1, AX 2012 and AX 2012 R2 ended on 12 April 2022. No security hotfixes or regulatory updates are now provided.

Can AX 2012 be upgraded directly to Dynamics 365? Yes, to finance and operations, but only from AX 2012 R2 or R3 updated to the latest cumulative update, and not from systems using virtual companies or data partitions.

Can we keep our transaction history? Yes. The data upgrade brings the database across with its full transactional history, which is the main advantage of upgrading over reimplementing.

Can AX 2009 be upgraded? No. Only AX 2012 R2 and R3 are supported upgrade sources, so an AX 2009 estate needs a migration or reimplementation.

How long does the data upgrade take? A single run can take several hours, and each debug, fix and rerun cycle in a larger sandbox takes several more. Plan for many runs, starting in a development environment.

Should we upgrade or reimplement? Upgrade when you are on R2 or R3, customisation is light, the data is clean and history matters. Reimplement when the upgrade path is blocked or the customisation mostly carries workarounds forward.

How many data upgrade runs should we expect? A clean run at the first attempt is rare. Two or three runs before one comes through clean is the normal shape, which is why the early ones belong in a development environment where a fix can be rerun in minutes.

What does the Upgrade analyzer check? It runs against the AX 2012 database and reports deprecated features, application and database settings, and space savings. It does not analyse code. Conflicts in customisations come from the separate code upgrade estimation tools.

What is Microsoft’s AIM offering? AIM, short for Accelerate, Innovate, Move, is Microsoft’s offering for qualified on-premises business applications customers, with a dedicated team of migration advisors and an assessment. It is worth asking about before committing to either route.

Gaurav Aggarwal

Cloud and enterprise architect with 17 years of experience across data platforms, integration and application development. Focus areas include Azure architecture, cloud-native application design, and ERP to data platform integration.