Ask anyone who has sat through a legacy migration what the worst phrase in the project plan is, and a surprising number won't say "change order" or "scope creep." They'll say "almost matching." It shows up in a status report sometime around month four of a parallel run, usually attached to a number in the high nineties, and it never leaves. Eighteen months later it's still there, still described as "close" — and the parallel run that was supposed to last one billing cycle is now a permanent second production environment nobody budgeted for.
What a parallel run is actually for
The idea is sound. Before cutting over from the mainframe system to its replacement, you run both systems side by side against the same live inputs and compare the outputs. If they agree, you've earned the right to flip the switch. If they don't, you've found a bug before it reached a customer, a regulator, or a payroll run — which is the entire point of doing this instead of trusting the new system and hoping. Done properly, a parallel run is the cheapest insurance policy in the whole project, because every discrepancy it catches is one that didn't have to be caught in production, with real money and real people on the other end of it.
The failure mode isn't the practice. It's what happens when nobody defines, in writing, before the parallel run starts, exactly what "matching" means.
The trap: matching becomes a moving target
Without a precise, pre-agreed definition of parity — this field, this precision, this rounding rule, this exact set of edge cases — "matching" quietly becomes whatever the team can currently explain. Week one, the outputs agree on the easy majority of transactions and diverge on the rest; that's normal, and it's why you run parallel in the first place. The trouble starts when the response to each divergence is a one-off explanation instead of a verified fix: "that one's a rounding difference, we know about it," "that one's a timing issue with the batch window, it'll settle," "that one only shows up on a leap year, we'll circle back." Each explanation sounds reasonable in isolation. None of them are checked against anything more rigorous than a person looking at two numbers and deciding they're close enough to wave through.
Multiply that by a system with decades of accumulated business logic — the informal patches, the "don't touch that field" comments, the tax-table edge case from a regulation nobody remembers changing — and you get a parallel run that never actually converges. It just accumulates a growing list of known, unresolved discrepancies the team has collectively agreed to stop being alarmed about. That list is where "almost matching" lives. It's a status, not a plan.
Why nobody stops it
The incentives inside a modernization contract make this drift almost self-sustaining. A vendor billing by the hour has no structural reason to accelerate a phase that bills by the month. A vendor under a fixed price has every reason to declare "substantially matching" good enough and push for cutover before the gap actually closes, because their meter stops at go-live, not at correctness. And the buyer's own team, worn down by months of "it's basically there," starts anchoring on the wrong question. Instead of asking "does this match, field for field, on a representative slice of real production data — yes or no," they start asking "is the trend line improving," which is a question that can be answered "yes" for years without ever reaching zero.
This is the same failure pattern that turns up in modernization post-mortems again and again: not one catastrophic bug, but a parallel run allowed to run indefinitely against a fuzzy target, quietly burning budget and morale until someone with signing authority decides the risk of continuing to wait outweighs the risk of cutting over with known gaps still open. That decision gets made under pressure, at the point of maximum fatigue — the worst possible moment to accept a lower bar than the one you started with.
Who actually pays for "almost"
The direct cost is obvious: extra months of dual infrastructure, dual support staff, and a project team that can't be reassigned because the migration technically isn't finished. The less obvious cost is what "almost matching" does to trust. Every stakeholder who signed off on the original business case watches the go-live date slip past its third or fourth revised estimate, and by the time cutover finally happens, the organization's appetite for the next modernization project — the one that would actually pay down the remaining technical debt — is gone. "Almost matching" doesn't just cost the current project. It taxes every future one, because it teaches the organization that "done" is negotiable.
What actually ends it
The fix isn't a better parallel run. It's a parallel run with teeth, defined before a single transaction is compared:
- Write the parity bar down first, as a number. Byte-exact, field-for-field, across a defined representative sample of real production inputs — not "substantially similar," which isn't a bar, it's an opinion.
- Automate the comparison. If a human is eyeballing two output files and deciding whether a difference counts, the bar will erode one reasonable-sounding exception at a time. A diff tool doesn't get tired of the argument.
- Treat every discrepancy as a defect, not a footnote. Log it, root-cause it, fix it, then re-run the full comparison — not just the one transaction that failed. A discrepancy explained away without a verified fix is a discrepancy that resurfaces the week after cutover, once nobody is watching for it anymore.
- Refuse to schedule a cutover date until the bar is met, not approximated. The moment a calendar date exists, "almost matching" becomes politically convenient. Don't give the drift a deadline to hide behind.
None of that is exotic. It's the difference between a parallel run that is a genuine gate and one that is theater with a spreadsheet attached. The organizations that get burned aren't the ones that ran a parallel test — they're the ones that never wrote down, in advance, what passing it was actually supposed to mean.