Upgrade from AX 2012 to Dynamics 365 without losing your history.
Extended support for AX 2012 ended in January 2023. The system keeps working, but every year the gap grows: no security fixes, fewer people who know the code, and integrations that get harder to keep alive. We move you to Dynamics 365 Finance & Operations in phases, with your customisations rebuilt as extensions and your historical balances intact.
What an AX 2012 upgrade actually involves
An AX 2012 to Dynamics 365 upgrade is not an in-place update. Dynamics 365 Finance & Operations runs in the cloud, uses a different code model (extensions instead of over-layering) and a different data layer. The work splits into three streams: code, data and process.
Code: every customisation in your AX 2012 model store is analysed. Some are already standard in Dynamics 365 and are dropped. Some are rebuilt as extensions. A few are replaced by configuration or a Power Platform component. Data: master data, open transactions and the historical balances your auditors and reports depend on are migrated with reconciliation reports at each step. Process: the people who run month-end, purchasing and warehouse operations test their real scenarios in the new system before anyone talks about go-live.
The result is a system that stays on Microsoft’s update cadence instead of a frozen version of 2012.
- You are still on AX 2012 with heavy customisation and nobody is sure what it all does
- Reporting and historical balances must survive the move, not just open balances
- You need a phased plan with a parallel-run period, not a big-bang weekend
- Your previous upgrade assessment stalled or came back with an estimate nobody believed
The steps, in the order they happen.
Code and data assessment
We run the Microsoft upgrade analysis tools over your model store and database, then read the results with your team. The output is a list of every customisation, what it does, and whether it is kept, dropped or replaced.
Scope and plan
A written plan: which legal entities move first, which integrations change, what the parallel-run period looks like and which month-end is the target. Scope is agreed in writing before any build starts.
Code migration to extensions
Customisations that survive the assessment are rebuilt as extensions using standard Dynamics 365 patterns, so future Microsoft update waves do not break them.
Data migration with reconciliation
Master data, open transactions and historical balances move through repeatable migration runs. Each run ends with reconciliation reports your finance team signs off, so the final run holds no surprises.
Parallel testing
Your process owners run the same month-end, purchase-to-pay and order-to-cash scenarios in AX 2012 and Dynamics 365 side by side until the numbers agree.
Phased cutover and hypercare
Go-live is planned around your close calendar, entity by entity where that reduces risk. We stay through the first month-end on the new system.
- Customisation inventory: keep, drop or replace, with reasons
- Code rebuilt as extensions, documented
- Historical balances migrated and reconciled
- Parallel test results signed off by process owners
- Phased cutover plan around your financial close
- Hypercare through the first month-end
What usually goes wrong, and what fixes it.
The customisation nobody can explain
A warehouse posting routine was changed in 2014 by a developer who left in 2016. Nobody knows why it exists. The assessment shows what it does; the process owner decides whether the standard behaviour is acceptable now. Usually it is.
Balances that do not tie out
Migrated trial balances differ from AX 2012 by a few hundred in one account. Reconciliation reports at each migration run find the posting profile behind it before go-live, not after the auditors do.
Integrations that only one person understood
The bank file export and the EDI link were built outside AX with no documentation. They are redesigned on data entities and Azure integration patterns with error handling you can see.
Frequently asked
It depends on the volume of customisation and the number of legal entities. A single entity with moderate customisation typically runs a few months from assessment to go-live; multi-entity, heavily customised systems take longer and move in phases. The assessment at the start gives you a dated plan rather than a guess.
Yes, if you need them. Historical balances and the transactions behind your reporting are migrated and reconciled. Some customers choose to migrate balances plus a few years of detail and keep AX 2012 read-only for older history; both are valid, and we help you decide.
Each one is assessed. Those already covered by standard Dynamics 365 functionality are dropped. Those still needed are rebuilt as extensions, which keep working through Microsoft’s update waves. Over-layered code cannot be carried over as it is.
Often, yes. A phased approach by entity or by business unit reduces risk and lets your team learn the new system on a smaller scale first. Intercompany processes need a plan for the transition period, which is part of the scope.
For most AX 2012 customers the natural path is Finance & Operations, because the processes and data model are closest. Smaller organisations with simpler needs sometimes fit Business Central better. The assessment answers this before anything is built.
Often combined with this service.
Support & Optimization
Dynamics 365 support from the consultant who knows your setup.
Integrations & Data
Integrations you can audit, built on data entities and Azure.
Articles on this topic.
AX 2012 extended support has ended: your four realistic options
Stay and harden, re-implement, upgrade with your history, or move to Business Central. What each one costs in time and risk.
How long does an AX 2012 to Dynamics 365 upgrade take?
A phase-by-phase answer, from code analysis to the first month-end on the new system.
Data migration from AX 2012: keeping historical balances intact
Open versus historical transactions, balance strategies, and the reconciliation that proves it.
Still on AX 2012? Start with an assessment.
Send us a few lines about your environment: entities, customisation level, integrations. We will tell you what the upgrade would involve and what the first step is.