Parallel Run

A payroll team calculates one pay period in its old system and in the proposed new system, then compares employee totals, deductions and exceptions before sending payment once, which is a parallel run with a safe distinction between calculation and final action. Oracle implementation guidance describes parallel running as part of transition, and Microsoft discusses cutover strategy and validation, but their product examples support the practice, not a rule that every business should run two live systems indefinitely.

Define the purpose first, whether to prove calculations, test workflow, compare reporting or train staff, because each needs a different evidence plan. Identify the old and new outputs to compare, since matching a headline total can hide wrong individual records, and set the period and sample scope in advance to include normal work and important exceptions, not only the easiest cases.

Decide which system has legal and operational authority during the run so staff know which output controls actual payments or orders, and do not duplicate real side effects, because sending two invoices, dispatching two shipments or paying employees twice is not a test. Where both systems receive production data, control access and protect personal information in each environment.

Record input snapshots and timing, because a difference may come from records changing between the two runs rather than a calculation defect, and write tolerances for expected differences such as rounding, taking care that a tolerance does not conceal a material customer error. Reconcile counts, amounts and exceptions, trace each discrepancy to a documented cause, and assign issue owners and severity, since a missing mandatory deduction or tax field may stop cutover while a display preference may not.

Train users on how to log differences, because informal comments are hard to verify and close. Include upstream and downstream integrations, since a new payroll calculation that is correct but fails to post to accounting is not ready, and test data migration separately from transaction comparison because both matter and one cannot prove the other.

Compare performance and capacity as well as numerical results, because a correct answer arriving hours late can be unusable, and review access controls and audit trails in the replacement, since a parallel calculation does not prove security is sound. Include business owners in sign-off, because technical teams may miss a report that operators rely on daily.

A parallel period adds labour, so budget for duplicate processing, checks and extra supervision, and remember that a long overlap can create confusion and diverging records, so set a realistic exit gate and a way to manage changes. The old system may have known errors, so matching its output exactly is not always the right target; investigate differences against policy and source records and document approved corrections, because a new system may legitimately produce a better result under an updated rule.

For time-sensitive operations, choose a testing window that leaves enough time to correct issues before a real deadline. Maintain rollback or forward-recovery plans, because a parallel run is evidence of readiness, not a guarantee against later failure, and customer-facing processes may use shadow mode, where the new system calculates an answer but does not send it, which should be labelled clearly.

Define exit criteria: critical discrepancies cleared or accepted, support ready, and the cutover decision documented, and if criteria fail, extend the test or delay cutover with a stated plan, since repeating the same checks without fixing issues adds little value. After switching, retain only the permitted historical access and retire redundant processing safely, because the run succeeds when it provides specific evidence for a decision, not merely when both systems have been left on for a month.