Dynamics AX 2012 to Dynamics 365 Finance & Operations
Cohash upgrades Dynamics AX 2012 R2 and R3 to Dynamics 365 finance and operations apps. Microsoft's upgrade analyzer and code upgrade tools go first. Overlayered X++ moves to extensions, and we clean and compress the database before rehearsing the data upgrade in development and then sandbox. We practice cut-over against the downtime you really have, and rebuild AIF services and reports on data entities.
- 01Upgrade analysis
- 02Code upgrade
- 03Data preparation
- 04Data upgrade rehearsals
- 05Integrations and reports
- 06Mock cut-over and go-live
The story
Told without the client's name or anything that could identify them.
A distributor's finance and operations team still ran Dynamics AX 2012 R3, which stopped getting Microsoft fixes in January 2023, so tax and e-invoicing changes were being patched in-house. Most customizations were overlayered changes to standard objects, and integrations ran through AIF services and file drops on Windows Server and SQL Server versions security wanted gone. We ran the upgrade analysis report and the Lifecycle Services code upgrade tool first, then froze AX 2012 code and moved overlayered X++ to extensions. After data clean-up and rehearsed data upgrades in development and sandbox, a mock cut-over was timed against the downtime limit before go-live on Dynamics 365 finance and operations apps.
why it was urgentAX 2012 R3 lost Microsoft support in January 2023. No security fixes and no regulatory fixes since then. The supported upgrade to finance and operations starts from AX 2012 R2 or R3 only. Systems with virtual companies or data partitions can't be upgraded at all.
- openTax and e-invoicing changes are now patched in-house because Microsoft no longer ships them for AX.
- recurringAX runs on Windows Server and SQL Server versions that security wants gone.
- blockedMost customizations are overlayered changes to standard objects.
- openIntegrations still run through AIF services and file drops.
The estate, before and after
Before: Dynamics AX 2012 R3 with overlayered code and AIF
AX 2012 R3 ran on-premises on SQL Server, with customizations overlayered onto standard objects. Partners exchanged data through AIF services and file drops, and attachments sat on file shares and SharePoint outside the database.
After: Dynamics 365 finance and operations apps in the cloud
After the upgrade, customizations are X++ extensions and the apps take Microsoft's update cadence. Partners use data entities, OData and the Data Management Framework. Where a process needs Dataverse, it comes in through dual-write or virtual entities.
How we run it, phase by phase.
6 phases take you from Dynamics AX 2012 R2 / R3 (on-premises) to Dynamics 365 Finance & Operations (cloud). Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Upgrade analysis
Run the upgrade analysis report on the AX 2012 database. It shows the cleanup, the settings and the deprecated features. Then export the model store to the Lifecycle Services code upgrade tool to see how big the conflict list really is.
- phase 02
Code upgrade
Resolve conflicts, move overlayered code to extensions, and freeze AX 2012 code except for emergencies, which are ported by hand from then on.
- phase 03
Data preparation
Old data is purged or archived and the biggest tables compressed. Attachments on file shares and SharePoint get pulled into the AX database first, since that's how the upgrade carries them to Blob storage.
- phase 04
Data upgrade rehearsals
Development gets a database backup first, and we keep upgrading it until a run comes through clean. Then the sandbox, this time with the AX 2012 Database Upgrade Toolkit replicating the data to Azure SQL.
- phase 05
Integrations and reports
Replace AIF services with data entities, OData and the Data Management Framework. Rebuild reports that won't upgrade, and connect Dataverse through dual-write or virtual entities where needed.
- phase 06
Mock cut-over and go-live
Time the technical and functional cut-over tasks together against the downtime limit, run a full functional test pass, then go live and move onto Microsoft's service update cadence.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Microsoft ships tax and regulatory updates again
The business runs on Dynamics 365 finance and operations apps, on Microsoft's service update cadence. Regulatory changes come from Microsoft now. Nobody writes in-house patches for them.
- result 02
Customizations are extensions in source control
Overlayered X++ now lives as extensions in source control. Service updates go on without anyone reworking standard objects by hand.
- result 03
Integrations run on data entities
The AIF services are gone. In their place are data entities, OData and the Data Management Framework, with Dataverse linked through dual-write or virtual entities wherever a process called for it.
- result 04
Attachments moved with the data
We loaded the attachments from file shares and SharePoint into the AX database before the upgrade, so the upgrade carried them to Blob storage.
- result 05
Go-live followed a rehearsed cut-over
We timed technical and functional tasks side by side in the mock cut-over, against the downtime limit. Production ran off that exact plan.
Risks we plan for
-
Blocked features
Virtual companies and data partitions stop the upgrade path. If the analyzer finds them, the plan becomes a reimplementation with data migration, and that's better known early.
-
Downtime that doesn't fit
Large databases can push the data upgrade past the weekend window. Cleanup, compression and tuning are done before the mock cut-over, because the window is fixed by the business.
-
Lost attachments
Attachments only come across if they are in the AX database before the upgrade. Moving a large file share in takes planning and test runs.
-
Update cadence after go-live
Microsoft ships four service updates a year for finance and operations, and you have to take at least two. If regression testing is manual, every one of those turns into its own small project.
Where AI helps, and where it needs guardrails
Once you're on finance and operations, Copilot Studio agents and Power Platform flows can get at ERP data through Dataverse, via dual-write and virtual entities. Give any agent that posts journals or approves purchase orders a dedicated user with a narrow role, and route it through the same workflow approvals as everyone else. On the upgrade itself, we lean on an LLM to triage conflict reports and draft X++ extensions, and our developers check each change.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- report01
Upgrade analysis summary with blockers and cleanup actions
yours to keep - code02
Upgraded code base as extensions, in source control
yours to keep - tests03
Data upgrade rehearsal log with timings per environment
yours to keep - code04
Integration map from AIF and file drops to data entities and APIs
yours to keep - runbook05
Cut-over runbook timed against the agreed downtime limit
yours to keep - tests06
Regression test suite for future service updates
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Service update
- One of the scheduled releases Microsoft ships for Finance and Operations. There are four a year, and you have to take at least two.in context →
- 02Lifecycle Services
- The older Microsoft portal where teams manage Finance and Operations projects and environments. The Power Platform admin center is taking over that job.in context →
- 03Dataverse
- The full Power Platform database. You get auditing, API access, model-driven apps and the rest, but it eats into your paid storage and needs Power Platform licences.in context →
- 04sandbox
- A non-production copy of your system that people test and train on. It eats into your storage just like production does.in context →
- 05extensions
- Custom code that sits beside Microsoft's code and adds to it without editing it. This is what lets Microsoft update Finance and Operations several times a year.in context →
- 06data partitions
- An AX 2012 R2 feature that kept groups of companies' data apart in one database. Finance and Operations dropped it, and its presence blocks the upgrade.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we upgrade or reimplement?
It depends on how much of AX still matches how you work and whether the analyzer finds blockers. An upgrade keeps transaction history and customizations. A reimplementation lets you drop old design choices but means migrating open balances and master data instead. We run the analysis first and price both.
02We're on AX 2012 RTM. Is there a path?
No. Microsoft won't take AX 2012 RTM straight to the cloud version. You'd either get to R3 first or treat the whole thing as a reimplementation.
03What drives the cost?
The number of overlayered objects and code conflicts, database size, the number of integrations and reports, and how many legal entities go live together.
04Can Cohash support us after go-live?
Yes. We take on service update testing, extension development, integration support and Lifecycle Services administration, with onsite, nearshore or offshore engineers.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyMoving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.
read the case study3fa2ccac - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it