Dynamics AX 2012 to Dynamics 365 Finance and Operations: How to Plan the Move
Moving from Dynamics AX 2012 to Dynamics 365 Finance and Operations is often described as an upgrade. In practice it is closer to a re-implementation that carries your business processes, data and lessons learned forward. Treating it that way from the start avoids most of the surprises.
1. Decide what the business needs, not just what AX does today
Start with the processes, not the code. Walk each finance, supply chain and warehouse process with the people who run it and ask what still earns its place. Years of AX 2012 use usually leave behind workarounds, duplicate reports and customisations that exist because of a limit that no longer applies. The move is the cheapest moment to drop them.
2. Triage every customisation
AX 2012 projects often relied on overlayering the base application. Dynamics 365 Finance and Operations uses an extension model instead, so each customisation needs a decision:
- Retire it if the business no longer uses it.
- Replace it with standard functionality where Dynamics 365 now does the job out of the box.
- Rebuild it as an extension where it still gives real business value.
Build a register of every customisation, who uses it and what it costs to rebuild. It becomes the backbone of your scope and your estimate.
3. Choose your data approach early
There is no single right answer for data. Some programmes use Microsoft's data upgrade path for AX 2012. Others migrate a defined set of master data, open transactions and balances into a clean environment and archive the history. The choice affects cost, timeline and how much legacy structure you carry over, so make it early and make it with finance and audit in the room. See my notes on a practical approach to ERP data migration for the detail on validation and reconciliation.
4. Plan integrations as a workstream of their own
AX 2012 integrations built on the Application Integration Framework (AIF), file drops and direct database access do not carry across. In Dynamics 365 you will typically use data entities, OData, custom services, Power Automate and, where it fits, dual-write with Dataverse. List every inbound and outbound interface, including warehouse systems such as SAP WMS and EDI partners, and decide for each whether to rebuild, replace or retire it.
5. Rethink reporting
SSRS reports can be rebuilt, but many organisations take the chance to move management reporting into Power BI on top of a governed data layer such as Azure SQL or Azure Data Lake. Agree which reports are operational (stay close to the ERP) and which are analytical (move to the data platform) before development starts.
6. Set up delivery discipline from day one
Dynamics 365 Finance and Operations rewards teams that use proper engineering practice: source control, build pipelines in Azure DevOps, automated regression testing and a clear environment strategy. Setting this up in the first weeks, not the last, makes every later phase quicker and safer.
7. Rehearse the cutover
Run several mock migrations and at least one full cutover rehearsal against the real timeline. Agree go and no-go criteria in advance, define who signs off the opening balances, and plan hypercare so that finance can close the first period with support on hand.
What to settle before you commit to a plan
- A list of processes that stay, change or go.
- A customisation register with a retire, replace or rebuild decision for each item.
- A data approach agreed with finance and audit.
- An integration inventory with an owner for each interface.
- A governance model covering vendors, partners, change control and release management.
Need help with a Dynamics 365 or ERP project?
I advise on architecture, implementation, integration and data migration for Dynamics 365 and enterprise platforms. Get in touch at declan@feelyconsultants.com or find me on LinkedIn.