An enterprise runs old and new systems in parallel to validate the replacement. What makes a parallel run effective, and what makes it expensive theatre?

What makes it effective

1. Automated comparison, not manual sampling. Every transaction processed by both systems, outputs compared automatically, discrepancies logged and categorised. Manual sampling checks a fraction and finds only the common differences, which are the ones you already know about.

2. Discrepancies triaged and resolved, not accumulated. Each difference is either a defect in the new system, an undocumented behaviour of the old one that must be reproduced, or an intentional change. The second category is the whole point — it is how you find the accumulated handling of real edge cases that exists nowhere in documentation.

3. Real traffic, real data, real volume. A parallel run on synthetic data validates the happy path, which is not where the risk is.

4. A defined exit criterion. Discrepancy rate below a threshold, sustained, with all remaining differences explained. Without one, the parallel run continues indefinitely because nobody is willing to say it is done.

5. Bounded duration. A parallel run is expensive — double processing, double infrastructure, and the reconciliation effort. It must end.

What makes it theatre

• Manual reconciliation of a sample, producing confidence rather than evidence.
• No triage process, so discrepancies accumulate in a report nobody works through.
• Both systems fed different inputs, so differences are inconclusive.
• Running only the happy path, which is not where the risk is.
• No exit criterion, so it becomes permanent and the organisation is paying for two systems with no plan to stop.
• Discrepancies explained away rather than investigated, which is what happens under schedule pressure and which destroys the entire value.

The relationship to traffic shadowing

For online systems, traffic shadowing is the lighter-weight equivalent: real requests sent to both, the old response served, both compared. It gives most of the parallel run's evidence at a fraction of the cost, and it can run continuously during an incremental migration rather than as a phase.

Full parallel run remains appropriate for batch and financial processes where the output is a periodic artefact — a settlement file, a regulatory report, a ledger close — and correctness must be demonstrated rather than sampled.

The judgement

A parallel run is a verification technique with a real cost, justified by the cost of being wrong. For a financial or regulatory system, that cost is high and the run is worth it. For a system where an error is visible and correctable, shadowing is enough.