Stop trusting the migration report. Start verifying the migration.

The most dangerous moment in any modernization program is the one everyone treats as a formality. The integrator presents a deck. Green checkmarks down the side. "Behavioral equivalence confirmed." A VP signs. The old system gets switched off that weekend. And on Monday, when a payroll batch lands eleven cents short on four thousand records, there is no way to go back and ask the deck what it actually checked — because the deck didn't check anything. A human looked at a sample, formed an opinion, and rendered it as a graphic.

We've spent the last stretch building for the assumption that this is unacceptable, and the surprising part is how rarely anyone questions it. The industry has quietly accepted that the proof a legacy system was faithfully replaced is a matter of testimony, not evidence. You trust the firm. You trust their process. You trust that the regression suite covered the path that broke. When TSB's 2018 platform migration went wrong, the cost wasn't the bug — it was that nobody could prove, before cutover, that the new core computed what the old one did. The post-mortem ran to hundreds of pages precisely because the equivalence had never been written down in a form anyone could re-run.

Equivalence is a fact, not an opinion

Here is the one claim this piece is built on: whether a reimagined system computes the same outputs as the legacy one is a measurable fact, and it should be recorded as a fact — field by field, on real inputs — not summarized as a verdict in someone's pipeline.

The mechanism isn't exotic. You record fixtures from the legacy system — the actual inputs and the actual outputs it produced. You replay those same inputs through the reimagined system. You diff the results field by field, with the differences ranked by severity, not hidden behind a pass/fail aggregate. Where the legacy output was a rounded penny, the new one had better be the same rounded penny. Where it wasn't, you see exactly which field, on exactly which record, diverged — before anyone cuts over, not after.

The objection writes itself: program equivalence is undecidable in general, so you can never prove two systems are identical for all inputs. True, and beside the point. We are not proving a theorem. We are proving that on the fixtures that represent how this system is actually used — the batch that ran last Tuesday, the edge cases compliance flagged, the records that historically broke — the reimagined system matched, to the field. That's a far weaker claim than universal equivalence, and it's exactly the claim a regulator, an auditor, or a nervous CFO actually wants. They don't want a proof about all possible inputs. They want to know the cutover won't move the money.

Make the proof outlive the program

The second move matters more than the first. Once you have a field-by-field equivalence result, you sign it — cryptographically, with the inputs, the outputs, the diff, and the name of the human who cleared the gate — and you write it to an append-only record. Not a log the vendor controls. A record the customer holds and can verify offline, after the engagement is over, after the integrator is gone, after the person who signed it has changed jobs.

A migration report tells you someone checked. A signed equivalence record lets anyone check, forever. Those are not the same product.

This is the part that changes the economics. When the proof is a deck, every future question — did the cutover change the tax calculation? was this field always like that? — reopens the original investigation, because the original investigation left nothing behind. When the proof is a signed record, the question is a lookup. The auditor doesn't trust you; they verify the signature and read the diff. That's not a nicer report. It's a different relationship to your own history.

None of this requires the modernization itself to be slower or more cautious. It requires the proof to be a designed artifact of the run rather than a narrative bolted on at the end. Assess the estate, rebuild it, prove the behavior matched, sign it — and the signature is the deliverable, not the deck. If you are about to switch off a system that has run your business for thirty years, the question worth asking your vendor isn't "are you confident." It's "can you hand me something I can verify after you leave."