AX 2012 upgrade to Dynamics 365: what moves and what is rebuilt

An AX 2012 upgrade to Dynamics 365 takes your AX 2012 database, with its full transaction history, and your custom code into Dynamics 365 finance and operations. Microsoft’s guidance divides an AX 2012 to Dynamics 365 upgrade into three phases. In the Analyze phase you estimate the work, and you can do it before you buy finance and operations. In Execute, the code is converted and the data is upgraded, first in a development environment and then in a sandbox. In Validate, the business tests the result, the cutover is rehearsed, and production goes live.

The upgrade path 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 walks through each phase, what carries across and what gets rebuilt, what drives the timeline, and when it is cheaper to start again.

AX 2012 R3 end of life: where AX stands today

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.

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.

That is the short answer on end of life. What staying on AX now exposes you to, including the platform underneath it, is covered in our AX 2012 support article.

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. The original AX 2012 release is not a direct source either: Microsoft states that upgrade from AX 2012 RTM isn’t currently supported, and its end-of-support guidance points AX 2012 customers to upgrade through AX 2012 R3.

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.

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 a typical AX 2012 upgrade involves, phase by phase

Microsoft’s documentation sets out an AX 2012 to Dynamics 365 upgrade step by step, and this is its sequence.

The Analyze phase: estimate before you buy

Microsoft says the Analyze phase activities “can be done before you buy finance and operations”. Apart from setting up a preview Lifecycle Services project with Microsoft’s AX 2012 upgrade methodology, four of them produce the estimate.

• The upgrade analysis report, a SQL script run against the AX 2012 business database that reports deprecated features, application and database settings, and table space savings. Its output becomes the plan for your AX system administrators. The script parses tables for application setup and data volumes; conflicts in customisations come from the next step.
• The code upgrade estimate. You upload an export of the AX 2012 model store to the Code upgrade service in Lifecycle Services, using its Estimation only option if you do not want a code branch yet. Microsoft says the analysis typically takes 40 to 60 minutes for a large solution, and that this step “forms the basis for the estimate of the cost of your code upgrade”. The service runs only in the United States region of Lifecycle Services, so a project elsewhere runs it from a temporary project created there.
• A demo environment with demonstration data and standard code, for a basic fit gap of AX 2012 processes that might have changed.
• A project plan from Microsoft’s template, covering data upgrade testing, mock cutover and the functional test passes.

The Execute phase: prepare AX, convert the code, upgrade the data

Execute starts when you buy finance and operations and move to the Microsoft-managed Lifecycle Services implementation project, which has to be identified as an AX 2012 upgrade; Microsoft calls that step “crucial”.

Prepare AX 2012. Your AX system administrator and database administrator work through the analysis report and the preupgrade checklist, which ships in AX 2012 R3 cumulative update 13 and needs KB 4048614 on R2. It validates the baseline version, keeps element IDs and security role assignments, maps each AX user to a Microsoft Entra account, and has to be rerun in full if objects, security or other parts of the AX environment change afterwards.

Convert the code. Developers resolve the conflicts the estimate found, and AX 2012 code is frozen: Microsoft’s guidance allows only emergency changes there, each ported to the new code base by hand.

Prepare the data. In a large database, Microsoft recommends compressing the largest tables. Clean-up follows, but Microsoft says a routine should run only “after the business has done detailed analysis and confirmed that the data is no longer required”. Attachments arrive only if they are in the AX 2012 database before the upgrade, so file share attachments are moved in first, and migration from a local SharePoint site isn’t currently supported.

Upgrade the data in development first. Restore an AX 2012 backup into a cloud-hosted or local VHD development environment, not a Unified Developer Experience one, and run the data upgrade package for your target version. A run can take several hours, but in development a fix can be made and the rerun started within minutes, where a sandbox needs several hours for each cycle.

The self-service data upgrade, step by step

The sandbox run uses Microsoft’s AX 2012 Database Upgrade Toolkit for Dynamics 365, which the self-service guide calls the Data Migration Toolkit, downloaded from the Lifecycle Services Shared asset library. It copies the AX 2012 database into the sandbox’s Azure SQL database by SQL replication, then triggers the upgrade there. Microsoft’s self-service guide requires a successful development upgrade with customer data on the same application version and customisations, toolkit version 1.0.12 or later, and a source SQL Server with replication enabled, SQL Server and Windows Authentication mode, a sysadmin SQL login and SQL Server Agent running. Microsoft recommends distribution and snapshot space of at least the size of the source database, and more if AX tables are compressed, because the snapshot is uncompressed.

1. Prepare. The toolkit validates the source and target, allowlists the source server’s IP address and sets the environment to Ready for replication.
2. Replicate. It sets up a distributor and publishes the primary key tables, each snapshot started by hand, one at a time, and then the database functions.
3. Cut over. It publishes the remaining tables and, once you have compared record counts between source and target with the toolkit’s validation report, removes the replication setup.
4. Transform. It triggers the upgrade inside the sandbox. If the upgrade fails, you fix the cause and resume, and Microsoft’s instruction is plain: “Repeat this step until the data upgrade is successful.” A rollback returns the data to its replicated state.

The toolkit runs only against sandbox environments: “It can’t be run against a production environment.” It cannot filter the rows it replicates, so clean-up has to happen in AX 2012 first. Source and target belong in the same region for replication performance, and for a go-live cutover Microsoft recommends starting replication the weekend before.

The Validate phase: testing, rehearsal and cutover

Functional test passes. Every business process is retested, both those brought forward from AX 2012 and new ones, and Microsoft warns that, depending on code quality, this “might require several iterations”. Old and new data are tested in combination: can you cancel a purchase order raised before the upgrade as well as one raised after it?

Mock cutover. Three workstreams rehearse together: the technical data upgrade, tuned if necessary to fit the business’s downtime limit; the functional configuration tasks that follow it, each with an owner and a duration; and a tested rollback to AX 2012.

Freeze, then rehearse again. AX 2012 code and configuration are frozen, and any code change made there has to be repeated in the new system, possibly with another round of testing. Microsoft calls it “critical” to run at least one final test data upgrade against the live AX 2012 production database, because active transactions affect replication in a way a copy does not, and to run it within a few weeks of go-live.

Go live. Even at cutover, the upgrade runs in the sandbox, not in production. AX 2012 is turned off, replication completes, the upgrade runs, and a self-service database refresh copies the result into production, followed by configuration, a smoke test and the return of users. Microsoft’s post-upgrade tasks follow, including moving attachments to Azure Blob storage and setting network printers up again.

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.

Microsoft’s sequence finds that code early. 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 before the timeline is agreed rather than after is the difference between a plan and a hope.

The compiler enforces this. Since version 8.0 the development tools do not allow overlayering of Microsoft code, so upgraded AX 2012 code that still overlayers fails to compile. The restriction can be relaxed while refactoring, but only on development and demo environments, and where an extension point is missing, Microsoft’s route is an extensibility request.

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. Some AX interfaces have nothing to port to: Microsoft removed AIF, AxD document services and the .NET Business Connector, with the Data Import/Export framework replacing AIF for recurring bulk import and export. 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.

Item by item, Microsoft’s upgrade documentation and its list of features removed as of Dynamics AX 7.0 give this picture.

What drives the timeline

Microsoft’s upgrade documentation gives no typical end-to-end duration for an AX 2012 to Dynamics 365 upgrade. It treats the project plan from the Analyze phase as the “data point that can help you understand the time and cost of an upgrade”, and it names what moves the date.

• Database size. A smaller database upgrades faster, and the toolkit replicates whatever was not cleaned up in AX 2012.
• Code conflicts. The code estimate is the basis for the code effort, and overlayering is what increases it, as described above.
• Data upgrade runs. A run can take hours and each sandbox fix several more, while in development a fix can be made and the rerun started within minutes, which is why Microsoft says starting there “helps reduce the overall time that is spent on iterations”.
• Code quality and test coverage. The number of functional test passes depends on code quality, and old and new data combinations multiply the tests; Microsoft’s advice is to decide consciously what to cover.
• The downtime limit. The technical and functional cutover tasks have to fit inside it together.
• Attachments, which “can take time to migrate based on the volume of the attachments”.
• Fixed gates. The Go-live Readiness Review falls no later than four weeks before go-live, and the final test data upgrade belongs within a few weeks of go-live.

Most of these are knowable early, from the analysis report, the code estimate and the first development run, which is the practical case for running all three before anyone commits to a date. What the upgrade costs is a separate question, covered in what a finance and operations implementation costs.

Data upgrade or data migration?

Data upgrade and data migration sound alike, but in an AX 2012 to Dynamics 365 move they are different routes. A data upgrade converts the AX 2012 database itself, using a framework Microsoft describes as largely the same as AX 2012’s own upgrade framework of X++ batch jobs, so the full transactional history, element IDs and security role assignments come with it.

A data migration is what a reimplementation does. Data is loaded through the data management framework, which Microsoft describes as a way to migrate “reference, master, and document data from legacy or external systems”, entity by entity. The project chooses what arrives, and Microsoft’s advice is to “Select only the entities you need to migrate”.

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. If Business Central is where you land, what support after go-live should cover is worth settling before you sign.

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. If the customer engagement side is in scope too, what moves the price of a Dynamics CRM implementation covers the licensing and capacity decisions there.

Frequently asked questions

What does an AX 2012 upgrade to Dynamics 365 involve? Three phases. In the Analyze phase you run the upgrade analysis report and the code upgrade estimate, which can be done before you buy. In Execute you prepare AX 2012 with the preupgrade checklist, convert the code, and run the data upgrade first in a development environment and then in a sandbox through the self-service toolkit. In Validate you run functional test passes and a mock cutover, then copy the upgraded database into production at go-live.

How long does an AX 2012 upgrade take? Microsoft’s upgrade documentation gives no typical duration; it points to the project plan built in the Analyze phase as the data point for time and cost. The main drivers are database size, code conflicts, test iterations and the business’s downtime limit. A single data upgrade run can take several hours, which is why the early runs belong in a development environment, where a fix can be made and the rerun started within minutes. Plan for several runs: Microsoft’s self-service upgrade guide says to fix the cause of each failure, resume, and “Repeat this step until the data upgrade is successful.”

When did AX 2012 R3 reach end of life? 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. What staying on it now exposes you to, and what the interim options buy, is covered in AX 2012 support: what running it now exposes you to.

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. AX 2009 is not a supported upgrade source, so an AX 2009 estate needs a migration or reimplementation. AX 2012 RTM isn’t supported directly either; Microsoft points those customers to upgrade through AX 2012 R3.

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. The data upgrade brings the database across with its full transactional history, which is the main advantage of upgrading over reimplementing.

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.