AX 2012 to D365 Finance and Operations.
A multinational life sciences enterprise needed off AX 2012 before support ran out. We provided the X++ developers and the functional lead behind their consulting partner, and ran the migration the way migrations survive: assessed honestly, rebuilt as extensions, and rehearsed until cutover was the least dramatic week of the programme.
The engagement
The client was a multinational enterprise in the life sciences sector, manufacturing and distributing regulated products across multiple regions on Dynamics AX 2012 as end of support approached. Years of customisation had accumulated in the estate, as it does in every AX system that has served a business well: the platform was where development budget went, so the platform is where everything ended up.
The engagement came through a consulting partner, the arrangement our partner augmentation work is built for: their brand and client relationship, their methodology, our specialists doing the work. Coder Trove provided X++ developers with AX-to-F&O migrations behind them, custom development capacity, and a Finance and Operations functional consultant who worked on site and led the rollout with the customer's own teams.
Deciding what deserved to survive
The cheapest path on paper is to carry everything across. It is also the path we have seen fail, because it migrates a decade of undocumented decisions along with the code, and every future Microsoft update has to be tested against all of it. So the programme started where our migrations always start: with the customisation layer inventoried and every item scored against the business as it operates today, not as it operated when the code was written.
That scoring is done with the people who use the system, function by function: still used, no longer used, or covered by standard Dynamics 365 capability that did not exist in the AX era. Customisations that earned their place were rebuilt as extensions rather than overlayering, so they survive Microsoft's continuous update cadence. Customisations that had quietly stopped mattering were retired instead of migrated, and every retirement removed permanent regression-testing cost from the client's future. The reasoning behind each call was written down, which is what lets a decision survive a steering committee.
The code and the pipelines
The technical workstream ran the upgrade path in full: codebase assessment with Microsoft's upgrade tooling, X++ moved from AX's overlayering model to D365 extensions, and conflicts resolved by developers who had made these calls on previous multinational migrations rather than discovering them for the first time on this one.
Every environment sat under automated build and release pipelines in Azure DevOps from the start. Code moved through development, test and production the same way every time, which is what made the later stages of the programme measurable: a cutover rehearsal only tells you something true if the process it rehearses is the process go-live will use. It also left the client with an estate ready for One Version, where updates arrive on Microsoft's schedule and the regression machinery has to already exist.
The data
Data migration was treated as the critical path from the first week, because on F&O programmes it is. Master data went first: customers, vendors, items and the chart of accounts, extracted, cleaned and validated before anything else moved, with the effort concentrated where it belongs, in the relationships between records rather than the records themselves. A migration is the one structured chance a business gets to clean its data, and a multinational estate accumulates a lot to clean.
Finalised master data and configuration were held in a controlled golden environment with tightly restricted write access, so what went to production at cutover contained exactly what had been signed off and nothing that had wandered in. Open balances and open transactions moved and were reconciled to the ledger. Deep transactional history was not dragged into the new system to slow it down; an ERP is an operational platform, not an archive, and the reporting need is better served elsewhere.
Then the rehearsals: full migration runs, timed and measured on error rates and runtime, each one compared against the last. By the final rehearsal the cutover window was a known quantity rather than an estimate, which is the difference between a go-live decision made on evidence and one made on nerve.
The rollout
Our functional consultant led the rollout on site, owning the conversations that decide whether a migration lands: process mapping against what standard F&O does, the fit-gap calls where the business had to choose between changing a process and paying for an extension, user testing and training with the customer's own teams, and the cutover plan itself.
On-site mattered. A migration is a change programme wearing a technology programme's clothes, and the functional lead's job in the room was as much about trust as configuration: the customer's process owners needed someone who could answer the hard questions in person, hold the line on scope when standard capability was good enough, and concede quickly when it was not.
The result
The rollout went live successfully across the client's regions. The partner kept the relationship, the customer kept a working system through cutover, and the estate landed on a supported platform with its customisation debt paid down rather than carried forward. On engagements like this the measure of success is quiet: month-end runs, orders ship, and nobody has to write about the ERP migration in the annual report.
The approach this programme ran on is documented in full in our AX 2012 to D365 migration guide.
Tell us where your AX estate stands.
Migrations reward experience. If your programme needs people who have made these calls before, at this scale, talk to us.