Ask people what went wrong on a difficult Dynamics 365 Finance and Operations programme and you will hear about scope, or the vendor, or change fatigue. Look at the project artefacts and you usually find something more specific: data migration started late, ran as a side workstream, and was rehearsed properly for the first time a few weeks before cutover.
By the time UAT starts, the outcome of an F&O programme is largely set. UAT finds configuration defects, and configuration defects are fixable in days. What UAT cannot fix is a customer master full of duplicates, opening balances that will not reconcile, or an extract-transform-load process that takes ninety hours when the cutover window is forty-eight.
On our programmes, data migration is on the plan from the first week, staffed as an engineering workstream rather than a task for whoever is free.
The ETL routines get built early and run often. Every run is measured on two numbers: error rate and runtime. Those two numbers turn a vague activity into an engineering problem with a trend line. If the error rate is falling and the runtime fits the cutover window, the programme is on track in the way that matters most. If nobody can tell you those numbers, the go-live date is a hope.
Master data comes first, because everything else hangs off it. Customers, vendors, items and the chart of accounts get extracted, cleaned and loaded before anyone worries about history. This is also the one structured opportunity the business will ever get to clean its data, and the businesses that take it seriously go live with an asset instead of a liability.
A cutover rehearsal is a full run of the real thing: extract from the live system, transform, load, reconcile, and time every step. The first rehearsal is always ugly. That is its job. The value is in the delta between rehearsals, which is why each one is measured against the last.
By the third or fourth run, the conversation changes character. Instead of debating whether cutover will work, the team is arguing about whether the window is forty hours or forty-four. That is the argument you want, because it is an argument about evidence.
The final cutover should be the best-rehearsed activity in the entire programme. On well-run programmes it is also the least dramatic, which is exactly the point.
The other decision that shapes migration effort is history. Open balances, open orders and inventory positions must move and must reconcile to the ledger. Years of closed transactions mostly should not. An ERP is an operational system, and loading a decade of history into it adds effort and running cost for very little operational return. Reporting needs are better served from a warehouse or lakehouse, where the history can actually be analysed.
We wrote more about this decision, and the rest of the migration path, in our AX 2012 to D365 migration guide.
If you are sponsoring an F&O implementation right now, there is one question that will tell you more than any status report: how many full migration rehearsals have run, and what were the error rate and runtime on the last one compared to the one before?
A programme that answers with numbers is in control. A programme that answers with a plan to start rehearsing soon has told you the go-live date is not real yet.
Marcel Rizzolo is Director of Coder Trove. Our Dynamics 365 practice covers implementation, migration and support across Finance and Operations, Customer Engagement and Business Central.