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.
Read the diagram as text
- Finance and warehouse users → Dynamics AX 2012 R3: AX client
- Trading partners → AIF services: file drops
- Overlayered X++ → Dynamics AX 2012 R3: customizes
- Dynamics AX 2012 R3 → SQL Server database: data
- Dynamics AX 2012 R3 → AIF services: integration calls
- Dynamics AX 2012 R3 → File shares and SharePoint: attachment links
- Dynamics AX 2012 R3 → Reports: report data
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.
Read the diagram as text
- Finance and warehouse users → Dynamics 365 F&O: browser
- Trading partners → Data entities and OData: OData · DMF
- Data entities and OData → Dynamics 365 F&O: data import · export
- X++ extensions → Dynamics 365 F&O: extends
- Dynamics 365 F&O → Attachments in Blob storage: attachments
- Dynamics 365 F&O → Dataverse: dual-write
- Dynamics 365 F&O → Rebuilt reports: report data
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
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 studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study3fa2ccac - 01Microsoft Lifecycle: Dynamics AX 2012 R3learn.microsoft.com ↗
- 02Microsoft Learn: Upgrade from AX 2012 to finance and operationslearn.microsoft.com ↗
- 03Microsoft Learn: Finance and operations service update availabilitylearn.microsoft.com ↗
- 04Microsoft Learn: unified developer experience for finance and operations appslearn.microsoft.com ↗
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