Many organizations still run Microsoft Dynamics AX 2012, an ERP that has served them well for over a decade. But mainstream support has ended, the infrastructure is aging, and every new customization makes the eventual move more expensive. This guide covers how we approach an AX 2012 to Dynamics 365 Finance & Operations upgrade.
Upgrade or re-implement?
The first decision is the most important one.
| Technical upgrade | Re-implementation | |
|---|---|---|
| Keeps transaction history | Yes | Usually only open items and balances |
| Opportunity to redesign processes | Limited | High |
| Effort on code | Convert existing customizations | Rebuild only what’s still needed |
| Best when | AX fits your processes well | Processes or data quality need a reset |
A technical upgrade uses Microsoft’s upgrade toolset to convert your AX 2012 database and code. A re-implementation starts fresh in D365 and migrates master data and open transactions. Many projects land on a hybrid: upgrade the data, but rationalize customizations aggressively.
Step 1: Assess what you have
Before estimating anything, inventory:
- Customizations: objects modified via overlayering, by layer and model
- ISV solutions: check whether each vendor has a D365 version, or whether standard D365 now covers the feature
- Integrations: AIF services, file drops, direct SQL, and third-party connectors
- Reports: SSRS reports, and Management Reporter definitions that will move to Financial Reporting
- Data volume: large tables you may want to clean up or archive before the upgrade
Step 2: Code upgrade, from overlayering to extensions
Dynamics 365 does not allow overlayering of Microsoft code. Every customization must become an extension using Chain of Command, event handlers, and table/form extensions. This is where most of the effort goes, and also where you get the most value: extensions survive Microsoft’s continuous One Version updates.
Tip: treat the code upgrade as a clean-up. In most AX 2012 upgrades we review, a meaningful share of custom objects can be retired because D365 now provides the feature as standard.
Step 3: Data upgrade
For a technical upgrade, the AX 2012 database is prepared, uploaded and run through the data upgrade process in a sandbox. Plan at least two or three mock upgrades to measure duration, fix data issues, and rehearse cut-over timing.
Step 4: Integrations and reporting
Replace AIF with OData data entities, custom services, or Business Events, ideally orchestrated through Azure Logic Apps or Functions for monitoring and retries. Move analytics to Power BI on top of Synapse Link or Microsoft Fabric.
Step 5: Test, train and go live
Build a regression suite with the Regression Suite Automation Tool (RSAT), run user acceptance testing with real business scenarios, and train users on the new D365 interface and workspaces. A rehearsed cut-over plan keeps go-live downtime predictable.
How long does it take?
For a typical mid-size AX 2012 environment, expect 6 to 12 months from assessment to go-live, driven mainly by the number of customizations and integrations.
Next steps
Our upgrade assessment gives you a costed roadmap comparing upgrade and re-implementation paths. Learn about our AX to D365 upgrade service or contact us to start the conversation.