Separate what is known from what still needs verification

Parallel running is the practice of operating a legacy system and its replacement simultaneously, feeding the same inputs into both and comparing the outputs over a defined period. The goal is not to test whether the new system works in isolation — that should already be established through earlier testing — but to confirm that it handles real operational data and produces results consistent with the existing system under live conditions.

This approach sits between full upfront testing and a direct cutover. In a direct cutover, you switch off the old system and rely entirely on the new one from a fixed point. In parallel running, both systems remain active, which means the business can fall back on the old system if discrepancies appear. That fallback capability is the principal reason organisations choose parallel running, particularly where errors carry financial, regulatory or operational consequences.

Parallel running does not, however, eliminate risk. It shifts certain risks — particularly the risk of data inconsistency between the two systems — into an ongoing operational problem rather than a one-time event. The old system continues to change state as new transactions arrive, and keeping both systems aligned requires deliberate effort throughout the parallel period.

How parallel running differs from other migration approaches

A phased rollout introduces the new system to a subset of users, locations or processes while the rest remain on the old system. Parallel running, by contrast, typically involves the same users or processes operating both systems for the same work. A pilot may run the new system with a small group before wider deployment, whereas parallel running is usually broader and focused on output comparison rather than user feedback.

The distinction matters because each approach addresses different risks. Phased rollouts manage change-adoption risk. Pilots validate usability and workflow assumptions. Parallel running validates data integrity and calculation accuracy. Understanding which risk you are addressing prevents you from choosing parallel running when another method would be more efficient.

When parallel running is justified

Parallel running is most commonly justified where the new system performs calculations, transformations or business rules that are difficult to verify through test data alone. Financial processing, regulatory reporting, commission calculations and complex pricing engines are typical examples. In these cases, the cost of an undetected error in production outweighs the operational cost of running two systems concurrently.

It is also useful when the legacy system has undocumented behaviour — rules that are embedded in old code but not captured in any specification. Parallel running can surface these hidden rules by revealing persistent output differences that no amount of upfront analysis has identified.

When parallel running adds cost without proportionate value

For straightforward data migrations — moving customer records, product catalogues or configuration data from one system to another — parallel running is rarely necessary. If the migration is a one-time transfer followed by the new system becoming the sole source of truth, the relevant checks are comparison and validation of the migrated data set, not ongoing parallel operation.

Systems with low transaction volumes or where errors are easily detected and corrected by users also gain little from parallel running. The overhead of dual operation may exceed the cost of fixing the occasional post-migration issue.

Operational mechanics

Parallel running requires a clear process for how data enters both systems. The options fall into two broad categories: manual dual entry, where staff input the same transaction into both systems, and automated duplication, where an integration layer or middleware writes to both systems from a single input.

Manual dual entry is straightforward to set up but introduces its own error source: the operator. Differences between system outputs may reflect input errors rather than system faults, which complicates reconciliation. Automated duplication removes the human-input variable but requires development effort and its own testing to confirm that data is written correctly to both targets.

Reconciliation is the central activity during parallel running. This means defining which outputs to compare, how often, and what tolerance is acceptable. For financial figures, the tolerance may be zero. For timestamps or derived metrics, some small variance may be acceptable if the underlying logic differs legitimately. The reconciliation process itself needs to be documented, assigned to specific people and time-boxed so that it does not become an open-ended exercise.

Defining the parallel period

The duration should be determined by what you need to observe, not by an arbitrary number of weeks. A useful starting point is to identify the longest complete operational cycle the system supports — for example, a monthly billing run, a quarterly reporting period or a full payroll cycle. The parallel period should be long enough to cover at least one complete cycle, plus enough additional time to investigate and resolve any discrepancies that emerge.

Ending the parallel period requires clear exit criteria. These typically include: all identified discrepancies explained and either resolved or accepted as known differences, a defined number of consecutive reconciliation cycles with no new issues, and sign-off from the business owner accountable for the system's outputs.

Treating parallel running as a substitute for testing

The most consequential mistake is assuming that parallel running removes the need for thorough upfront testing. Parallel running is a verification layer, not a discovery mechanism. If the new system has fundamental defects — broken workflows, missing permissions, incorrect integrations — parallel running will reveal them, but at a far higher operational cost than finding them during testing. By the time you reach parallel running, the new system should already be functionally sound.

Undefined reconciliation rules

Starting parallel running without agreeing what constitutes a match, a mismatch and an acceptable variance leads to endless debate. One team may flag every decimal-place difference; another may dismiss material discrepancies as rounding. The reconciliation rules should be documented before the parallel period begins and should cover: which fields or outputs are compared, the comparison method (exact match, within tolerance, after normalisation), who adjudicates disagreements, and the escalation path when the source of a difference is unclear.

Underestimating the operational burden

Staff performing dual entry or reconciliation are doing additional work on top of their normal responsibilities. If this is not planned for — through temporary resourcing, reduced workload elsewhere or clear time allocation — the parallel period will be rushed, reconciliation will be superficial, and the exercise will deliver less assurance than it should. The cost of parallel running is not limited to infrastructure; it includes the ongoing time of the people operating it.

Drift between the two systems

During the parallel period, the old system continues to evolve. Corrections are made, new entries are added, and its state changes. If the new system is not updated to reflect these changes — or if the synchronisation mechanism introduces delays — the two systems will diverge for reasons unrelated to any defect in the new software. Establishing a clear rule for which system is the master during the parallel period, and how changes in one are reflected in the other, prevents this drift from undermining the comparison.

Absence of a stop condition

Parallel running that lacks a defined end point tends to extend indefinitely. The business becomes accustomed to the safety net, and no one is willing to sign off on the switch. This is costly and also risky: the longer two systems run in parallel, the more opportunities arise for divergence, and the more organisational energy is consumed by reconciliation rather than by operating the new system. The exit criteria should be agreed before the parallel period starts and reviewed at a fixed checkpoint rather than left open.

Key checks before starting parallel running

  • Both systems are on stable infrastructure with separate, reliable backups.
  • Reconciliation rules are documented and agreed by the business owner and the delivery team.
  • Staff involved in dual entry or reconciliation have been briefed and have protected time allocated.
  • Exit criteria are defined, including the minimum number of clean reconciliation cycles and the sign-off authority.
  • A process exists for logging, investigating and resolving discrepancies, with clear ownership and time limits.
  • The master-data source during the parallel period is explicitly identified and understood by all parties.
  • The transition from parallel running to full cutover is planned as a separate step, with its own checklist — not treated as something that will happen organically once parallel running feels safe enough.

Leave the next team with verifiable evidence

Parallel running is a targeted assurance measure, not a universal safety net. Applying it where the risks justify the cost, defining its rules before it begins and committing to a clear exit point allows it to deliver genuine confidence without becoming an indefinite operational burden.