Running Old and New Systems in Parallel

What parallel running means

In parallel running, the old and new systems both operate for a period after the new one is introduced. Users carry out the same work in both, or the same inputs are fed to both, and the results are compared. Only when the organization is satisfied does it stop using the old system.

It is one of several ways to reduce the risk of a cutover. It differs from a phased cutover, where different groups move at different times, because here the same work is being done twice. The wider choice between all-at-once and staged switching is covered in the cutover comparison in this cluster.

When it can help

Parallel running tends to make sense when:

• Accuracy is critical and errors are costly to correct, such as payroll, financial calculations or regulated reporting.
• Results can be compared objectively, for example totals, balances or calculated outputs.
• A cycle needs to be proven. Some processes only show problems at month-end or year-end, so one full cycle in parallel can build confidence.
• Trust is low. Users and managers may accept the new system more readily if they have seen it produce the same results as the old.
• Rollback would be difficult, and the parallel period works as a safety net.

For a financial close process, for instance, a team might run one month-end in both systems and compare the figures, investigating differences before relying on the new one. Whether this is necessary depends on the organization’s controls and risk appetite, and finance and audit specialists should advise on what is appropriate.

What it costs

The drawbacks are real, and they are why parallel running is not the default.

• Double work. Staff enter or process data twice, or reconcile two outputs. This is often the largest cost.
• Fatigue and errors. Doing everything twice is tedious, and people may become careless or resent the extra load.
• Confusion. It may be unclear which system is the record. If they disagree, whose answer counts?
• Delayed benefits. The efficiency gains of the new system are postponed while the old one is still needed.
• Extended licence and support costs for the old system.
• Pressure on support teams, who must look after both environments.
• Weak commitment. If staff know the old system is still there, they may delay learning the new one.

Parallel running also does not prove everything. It tests the output for the specific cases that occurred during the period, not for every possible case, and differences between systems can reflect intended design changes rather than errors.

Designing a parallel period

Decide the scope

Parallel running need not cover everything. It may apply to only the highest-risk processes, a sample of transactions, or a single department. The narrower the scope, the lower the burden.

Declare the system of record

State clearly which system is authoritative during the overlap. Commonly the old system remains the record until sign-off, and the new one is being verified. Make the rule explicit so that nobody has to guess.

Define how you will compare

Agree in advance:

• What outputs will be compared, such as totals, reports or sample transactions.
• What differences are acceptable, if any, and what counts as a material discrepancy.
• Who investigates differences and how fast.
• How findings are logged and categorized, for example as data error, configuration error, user error, or intended change.

Illustratively, if the old system calculates a total of 250,000 and the new one produces 249,500, the 500 difference needs an explanation even though it is small. It might be a rounding rule, a timing difference or a real defect. The logged cause matters more than the size.

Reduce the double entry

Where possible, feed both systems from the same input, or have one system’s data copied to the other automatically, instead of asking people to type everything twice. Be careful with copying, however, since a poorly designed link can itself introduce errors or mask them.

Set a fixed end

The most common mistake is letting the parallel period drift on. Set exit criteria and a time limit from the start. Examples of exit criteria:

• Agreed comparison checks pass for a defined number of cycles.
• No open critical defects.
• Business owners sign off.
• Users are comfortable working in the new system.

Decide what happens if the criteria are not met by the end date: extend for a stated period, or take the decision to roll back or roll forward. A rollback plan should already exist.

Ending the overlap

When the criteria are met:

1. Announce the end date well in advance, and keep it.
2. Make the old system read-only, so nobody continues to work in it by habit.
3. Keep it available for lookups for a defined period.
4. Move on to retirement, covering archiving and access removal, as described in the decommissioning article.
5. Reduce extra support arrangements.

Monitoring adoption measurement data after the switch can show whether people have actually moved, or whether they are quietly using old tools.

Alternatives

If a full parallel run is too costly, there are lighter options: a pilot with a small group, a simulation using copies of real data, or an extended test period with reconciliation checks. These may give much of the reassurance for less effort, though they test different things.

Summary of the trade-off

Parallel running buys reassurance and pays for it in effort, time and complexity. It suits situations where accuracy matters most and comparison is practical. It is less suited to cases where the double work is heavy and the risk of a short, well-tested cutover is acceptable. The right balance depends on the organization, and the outcome of any approach remains uncertain.