Skip to content

Parallel Run

Redundant operation method — instantiates Controlled Phase Transition

Runs the old and new regimes side by side over the same work for a bounded window, reconciling their outputs so the new one earns trust before the old one is switched off.

A Parallel Run keeps the old and new regimes both live at once, each processing the same real work, for a bounded overlap window during which their outputs are compared. Its defining idea is validation by concurrent redundancy: the new regime is not trusted because it was tested, but because it produced the same answers as the incumbent on live inputs, in real time, while the incumbent was still there to catch it. The overlap is doing double duty — it is both the evidence engine (every discrepancy between old and new is a defect surfaced before commitment) and the safety net (if the new regime falters, the old one is already carrying the load). It answers "does the new regime agree with the old on the real work?" — not how we sequence cohorts and not when we finally retire the old.

Example

A mid-size employer is switching payroll systems. Getting a paycheck wrong erodes trust instantly and is hard to unwind, so instead of cutting over on a chosen pay date, the company runs both systems in parallel for three consecutive pay cycles. Every cycle, the same time sheets, tax tables, and benefit deductions flow through both the legacy system and the new one, and a reconciliation compares the two paycheck-by-paycheck. Only the legacy system's output is actually paid; the new system's is shadow output. Cycle one surfaces forty mismatches — mostly a garnishment rule and two overtime edge cases the new configuration handled differently. Cycle two, after fixes, has three. Cycle three has zero. During the whole window the old system is the live scaffold that keeps employees paid correctly, while the new one accumulates the track record that lets the company trust it. The overlap ends not on a calendar date but when the new regime has matched the old cleanly enough to stand alone.

How it works

  • Feed both regimes the same live inputs. The comparison is only meaningful if old and new see identical real work, not a test harness.
  • Designate one output as authoritative. Usually the incumbent's; the new regime runs as shadow until it earns primacy.
  • Reconcile every cycle and triage discrepancies. Each mismatch is a defect or an expected difference; both must be explained, not averaged away.
  • Keep the old regime a real fallback. Because it is genuinely operating, it can absorb load instantly if the new one is pulled.
  • Exit on agreement, not on a date. The window closes when discrepancies fall to a pre-agreed floor.

Tuning parameters

  • Overlap duration — longer accumulates more evidence and spans more edge cases, but doubles operating cost and staff load for the whole window.
  • Reconciliation tightness — exact match vs. tolerance band. Tight catches subtle defects but drowns the team in benign differences; loose moves faster but can pass a real bug.
  • Authoritative-output choice — old-as-truth (safest) vs. flipping to new-as-truth partway (bolder, tests the new regime under real stakes sooner).
  • Coverage — all work in parallel vs. a representative sample. Full coverage is thorough but expensive; sampling is cheaper but can miss rare cases.
  • Exit threshold — how close to zero discrepancy the new regime must reach before the overlap is allowed to end.

When it helps, and when it misleads

Its strength is that it is the most rigorous way to earn trust in a new regime for high-stakes, hard-to-reverse work: parallel running against a live incumbent[n1] catches configuration and edge-case defects that no offline test reproduces, and it never leaves the system without a working fallback.

Its failure mode is carrying the overlap too long or too shallow. Running both systems is expensive and doubles the operational burden, so teams under strain start rubber-stamping the reconciliation — reviewing summaries instead of discrepancies — and the parallel run becomes a costly formality that validates nothing. The opposite error is a permanent parallel run: the overlap never ends because no one will own the decision to switch off the old regime, and the organization pays double indefinitely. The discipline is a pre-agreed exit threshold and a genuine reconciliation of every material discrepancy — the overlap has to be able to both fail the new regime and to end.

How it implements the components

  • parallel_operation_window — it is the bounded interval of concurrent old-and-new operation, with the reconciliation and exit rule that govern the overlap.
  • intermediate_state_scaffold — the still-live old regime is the temporary support that keeps the system functioning while the new regime is not yet trusted; the overlap is the scaffold.

It does not flip everything in a single timed event (cutover_criterion — that's Cutover Runbook), decide when the old regime is finally decommissioned (legacy_sunset_rule — that's Stabilization Period), or sequence the population across in waves (staging_rule — that's Phased Rollout).

Editorial Notes

Form Classification

Form family: Experiment, Test & Rehearsal

Rationale: Parallel Run operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it runs the old and new regimes side by side over the same work for a bounded window, reconciling their outputs so the new one earns trust before the old one is switched off.

Independent corroboration: The frozen evidence defines Parallel Run as 'Runs the old and new regimes side by side over the same work for a bounded window, reconciling their outputs so the new one earns trust before the old one is switched off', so its operative form is Experiment, Test & Rehearsal.

Nearest alternative: Protocol, Workflow & Routine — Parallel Run includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation.

Review outcome: Independent reviewer agreement; medium confidence.

Origin Attribution

Primary origin: Computer Science & Software Engineering

Origin pattern: Convergent development

Present-day reach: Multi-domain

Rationale: Information-systems migration practice established parallel running of legacy and replacement systems so outputs can be compared before an irreversible cutover.

Related originating lineages:

  • Accounting & Auditing — Accounting practice independently developed parallel books and reconciliation before system conversion.
  • Engineering & Design — Parallel Run is most directly rooted in engineering and design's traditions of specification, testing, reliability, control, and physical-system construction. The lineage fits its defining practice: Runs the old and new regimes side by side over the same work for a bounded window, reconciling their outputs so the new one earns trust before the old one is switched off.
  • Organizational & Management Science — Parallel Run also draws materially on organizational and management science's practice of coordinating people, authority, strategy, knowledge, and work, which shaped this mechanism rather than merely adopting it as an application.

Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of computer science. Parallel Run Pattern — AWS Prescriptive Guidance documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=multi_domain; origin_mode=convergent describes the historical relationship among lineages.

Review outcome: Researched adjudication after independent review; high confidence.

Sources consulted:

Notes

A parallel run produces the evidence that the old regime is safe to retire, but it does not own the retirement decision itself: it says "the new regime now agrees," while the formal rule for when the old regime is switched off — and the protected watch that must pass first — belongs to Stabilization Period. Keeping those separate stops a clean reconciliation from being read as license to decommission the old system the same afternoon.

[n1] Parallel running is the standard changeover method in accounting and information-systems practice: the new system is operated alongside the old on the same data until its results reconcile, precisely so the incumbent remains a live fallback throughout.