The numbers will not match, and being right will not save you
The better the migration, the more the old and new platforms disagree — and the burden of proof is entirely yours.
This is the lesson I would most want a first-time migration lead to absorb, because it arrives after the technical work has succeeded and it catches teams entirely unprepared.
However good the migration, the old and new platforms will produce different numbers. And the better the migration is, the more they will differ.
That is not a paradox. If the new platform has better data quality, more accurate metrics, corrected transformation logic or a fixed defect that had been quietly wrong for years, then every figure that defect touched now differs from the one the business has been reading. A migration that changes nothing produces no divergence. A migration that improves things produces divergence in direct proportion to how much it improved.
The burden of proof is entirely on you
Users trust the platform they have used for years. It is the one that produced the number in last quarter’s board pack, the one they have reconciled against monthly, the one they have built a mental model of. Its output is not just familiar — it is, in the working definition that actually operates inside an organisation, correct. Correct means “the number I have been seeing.”
So when the new platform disagrees, the presumption is not that the old system was wrong. The presumption is that the migration is broken. Every discrepancy is treated as a defect in your work until you prove otherwise, and that presumption does not shift because you have a good technical argument. Knowing you are right is the beginning of the conversation, not the end of it.
The cost of this is real and it is mostly borne in the wrong currency. Each unexplained difference consumes the migration team’s credibility, and credibility is what you need to get the remaining work funded and accepted. A programme can be technically flawless and still fail here.
It takes months, and it can reach the market
Proving out a genuine divergence is forensic work. You are reconstructing why a legacy transformation produced a particular figure, often from code nobody has read in a decade, and demonstrating both what the old platform did and why the new answer is the right one. Doing that convincingly for a single contested metric can take weeks. Across a reporting estate it takes months, and it runs long past handover — typically after the migration team has been stood down and the people who understand both platforms have moved on.
At the top end, the stakes are considerably higher than credibility.
On one programme, the old and new platforms disagreed on a set of externally reported metrics and neither could prove itself, because each was arguing from the transformation logic that was in dispute. Settling it took three people nine months of manual reconstruction from the feeder systems. The new platform was 99.4% accurate; the old one materially worse; the organisation restated to the markets. Field note: Nine months to prove we were right
Two things in that are worth sitting with. The first is that being right bought nothing — twenty-seven person-months were spent proving a conclusion that was already known, because knowing is not the same as being able to demonstrate. The second is the 99.4%. Even the winning answer was not perfect, and that residual is part of why the work took so long: you cannot close an investigation like this by finding the new platform correct, only by explaining every remaining difference.
If your platform feeds anything externally reported — financial statements, regulatory returns, market disclosures, published operational metrics — you need to establish this exposure during discovery, not during reconciliation. The question to ask, early and of the right people, is: “if this migration demonstrates that previously reported figures were wrong, what happens?” The answer shapes the migration.
What to actually do
Separate migration correctness from data correctness. These are different acceptance questions and bundling them is fatal. The migration is accepted when the new platform does what was specified. Whether a metric’s definition should change is a separate business decision with separate approval. If the two are merged, the migration cannot be signed off until every historical definition dispute in the organisation has been resolved, which is to say never.
Treat every intended improvement as a business change, decided in advance. If you are fixing something that will change a reported number, that is a decision for the business owner of that number, made at design time and documented. Never let an improvement arrive as a surprise in a reconciliation — at that point it is indistinguishable from a defect, and you have handed the sceptics their argument.
Preserving a known defect is a legitimate option. Sometimes the right call is to reproduce the old behaviour faithfully, wrong logic included, complete the migration, and then correct it afterwards as a separate governed change with its own approval and its own restatement plan if needed. Bundling a correction into a migration makes the migration carry the political cost of the correction. That is often a price not worth paying, and choosing not to pay it is not cowardice — it is sequencing.
The arbiter is upstream, not in either warehouse. When two platforms disagree about a derived figure, neither can adjudicate, because each is reasoning from the transformation logic that is itself in dispute. The only authority is the feeder systems. That has a consequence worth acting on before you need it: identify your genuinely contested metrics early, and reconstruct one or two of them from source, by hand, at small scale, while there is no pressure and no audience. It is tedious and it feels like make-work. It also establishes the method, proves the feeder data is still obtainable, and gives you a defensible answer ready before the argument starts rather than nine months after.
Build the divergence catalogue before users find it. During the dual-running or validation period, compare systematically and classify every difference into three buckets: a migration defect to fix, a known and intended improvement with a named business owner and an explanation, or unexplained. The third bucket is the one that matters. Drive it to zero before release, or accept each remaining item explicitly. The worst possible position is a user discovering a difference you cannot account for.
Pre-commit the message. Tell the affected users, before cutover, that specific numbers will change and why. Naming a difference in advance costs nothing and changes the frame completely — from “the new system is broken” to “this is the improvement they told us about.” After the fact, the same explanation sounds like an excuse.
Keep the old platform — and the feeder systems — investigable. You cannot forensically reconcile against a system you have decommissioned. Preserve not just the data but the ability to run the old transformations and reproduce the old figures, for as long as divergences are still being contested. Extend the same thinking upstream: if the tie-breaker is the feeder systems, then feeder extracts covering the disputed periods need to be retained too, and those systems are often on their own decommissioning path that nobody has told you about. This is a direct and expensive argument against early decommissioning, and it is a cost worth putting in the business case rather than discovering later.
Fund and staff the divergence workstream past handover. Give it a name, an owner, a budget and a duration measured in months. It will exist whether or not you plan for it. The only choice is whether it is a resourced workstream or an unbudgeted drain on a service team that has just inherited a platform it did not build.