Dynamics AX 2012 has served many businesses well for over a decade. But mainstream support has ended, the infrastructure it runs on is ageing, and the people who know it are getting harder to find. Moving to Dynamics 365 Finance & Operations is the natural next step, but it is a project, not a patch. This checklist walks through the decisions and work involved, in the order we tackle them.
1. Take stock of what you really use
Before choosing an approach, build an honest picture of today’s system:
- Modules and processes in use. List the modules you rely on and, just as important, the ones you no longer need.
- Customisations. Inventory every modification: what it does, who uses it and whether standard Dynamics 365 functionality now covers it.
- ISV solutions. Check whether each add-on has a Dynamics 365 version, and what it costs.
- Integrations. Map every system that sends data to or receives data from AX: banks, e-commerce, warehouses, payroll and reporting.
- Data volumes. Note database size and the largest tables. Old transactional history is often the biggest driver of migration effort.
- Reports. Identify which reports people actually open.
The output is a short list of what must come across, what can be replaced by standard features and what can be retired.
2. Choose the approach: upgrade or reimplement
There are two broad paths:
- Technical upgrade. Your AX 2012 data and configuration are upgraded to Dynamics 365 using Microsoft’s upgrade tooling, and your custom code is rebuilt as extensions. This preserves history and familiar processes.
- Reimplementation. You start with a clean Dynamics 365 environment, configure it around today’s processes and migrate only the data you need, typically master data, open transactions and opening balances.
An upgrade suits businesses whose processes are sound and whose data is clean. A reimplementation suits those carrying years of workarounds, or planning to change how they work anyway. Many projects land in between: an upgrade combined with a deliberate clean-up.
3. Rebuild customisations as extensions
AX 2012 allowed changes directly to Microsoft’s code (“overlayering”). Dynamics 365 does not: customisations must be built as extensions, using techniques such as Chain of Command and event handlers. This is what keeps your system upgrade-safe.
For each customisation in your inventory, decide whether to:
- Drop it, because standard functionality now covers the need.
- Replace it with configuration or an ISV solution.
- Rebuild it as an extension, ideally simplified.
Expect this step to remove a meaningful share of old code. Every customisation you don’t carry forward is one less thing to test and maintain.
4. Plan the data migration
Whichever path you choose, plan data early:
- Clean before you move. Duplicate customers, inactive vendors and obsolete items are cheaper to fix at the source.
- Decide how much history to bring. Full history comes with an upgrade. For a reimplementation, many businesses migrate open items and balances, and keep AX available read-only (or archive it) for older records.
- Use the Data management framework for repeatable imports, and rehearse the full migration more than once.
5. Re-plan integrations
AX 2012 integrations often relied on AIF services or direct database access, neither of which carries over. In Dynamics 365 you will use:
- OData and custom services for real-time, request-based integration.
- Business events to notify other systems when something happens.
- The Data management framework (including recurring integrations) for bulk and file-based exchanges.
- Dual-write or virtual entities if you also use Dataverse and the Power Platform.
Integrations are a common source of late surprises, so prototype the riskiest ones early.
6. Reporting
Most SSRS reports can be brought across, but this is a good moment to rethink. Operational reporting often moves to Power BI, which connects to Dynamics 365 data through the Microsoft-supported options for analytics. Retire the reports nobody reads.
7. Test like you mean it
Plan for several rounds of testing:
- Unit and integration tests for every extension and interface.
- End-to-end process tests (order to cash, procure to pay, record to report) with real users.
- Automated regression tests, for example with the Regression Suite Automation Tool (RSAT), which pay off with every future update.
- A full dress rehearsal of the cut-over, including data migration timings.
8. Cut over and stabilise
A good cut-over plan lists every task, owner and timing. It includes a clear go/no-go decision point and a rollback plan. After go-live, schedule hypercare: a few weeks of close support while users settle in and the first period-end closes.
How long does it take?
It depends on scope, data volumes and the number of customisations and integrations. A focused upgrade for a single legal entity can take a few months; a multi-country reimplementation can take considerably longer. A proper assessment (step 1) is the only reliable way to size it.
Where we can help
We help businesses and Microsoft partners with every step above: the initial assessment, rebuilding customisations as extensions, data migration, integrations and hypercare. If you are planning a move from AX 2012, we’re happy to look at your system and suggest a realistic plan.