Parallel Run
Operating the old and new systems simultaneously on the same inputs and comparing outputs, to build evidence that the replacement is correct before relying on it.
For a system whose correctness is critical and whose behaviour is imperfectly documented — a billing engine, a pricing calculator, a regulatory report, a payroll — a parallel run is often the only way to establish confidence, because the specification of what the legacy does is the legacy.
The method: feed both systems the same inputs, compare outputs automatically, and investigate every difference. The legacy remains authoritative throughout; the new system is being observed.
What makes it work in practice: automated comparison at the field level with tolerance rules for acceptable differences such as rounding, since manual comparison does not scale past a sample; triage discipline, because differences arrive in volume at first and the majority are environmental or data-related rather than genuine; and a defined exit criterion agreed in advance — a specified period with differences below a threshold, all unexplained differences resolved — or the parallel run continues indefinitely by inertia.
The finding to prepare stakeholders for, because it is common and politically awkward: a proportion of the differences will be defects in the legacy system that the business has been living with, sometimes for years, and sometimes with financial consequences. Deciding whether the new system should reproduce the bug or fix it is a business decision that needs an owner before the first one is found.
The cost is real — two systems, dual data feeds, and the comparison harness — which is why it is reserved for the cases where being wrong is expensive.