Parallel Site or System Run¶
Parallel-operation process — instantiates Managed Retreat
Runs the old and the new configuration side by side long enough to move every dependency and prove continuity before the old one is cut off.
The riskiest instant in any move is the hard switch — the moment the old thing goes dark and everything now depends on the new thing working. Parallel Site or System Run removes that instant by running the old and the new configuration simultaneously for a bounded window, carrying real load on both, until every dependency has been transferred and continuity is proven — and only then cutting the old one off. Its defining feature is temporal overlap: for the length of the run there is no single point of failure, because the thing you are retreating from is still live and can carry the load if the destination stumbles. That overlap is what converts an all-or-nothing leap into a reversible, evidence-generating transition — and what keeps rollback a real option instead of a slogan, right up to the cutoff.
Example¶
A bank is replacing a decades-old core banking platform. A flip-the-switch cutover is unthinkable: if the new core mishandles interest accrual or a payment rail on day one, the failure is customer money. So the two cores run in parallel — for a defined window both process the same transactions, the new one shadowing the old, with nightly reconciliation comparing balances, posted interest, statements, and settled payments account by account. The continuity criterion is explicit and money-shaped: end-of-day balances, interest, and payment outcomes must match to the cent across both systems for N consecutive business days before cutoff. Discrepancies surface — a rounding rule here, a timezone edge case on cutoff times there — and get fixed while the old core is still the system of record and no customer is exposed.
When the match holds for long enough, they cut over. Because the old core is then kept warm for a further window, a serious post-cutover surprise can still roll back to it. The parallel window is expensive — two cores, double the reconciliation — which is precisely why it is bounded and ends in a declared decision.
How it works¶
- Run both live at once — the new configuration carries real load alongside the old, which serves as the live oracle it is proven against, rather than being tested in a lab.
- Prove an explicit continuity match — continuity is defined as a checkable match on the functions that must not break, and that match must hold for a set number of clean cycles before cutoff.
- Keep the incumbent recoverable — the old configuration is held warm and recoverable through and past cutoff, so reverting stays a live, rehearsed option until confidence is earned.
Tuning parameters¶
- Overlap duration — how long both run. Longer buys confidence and catches rare or periodic edge cases (month-end, leap day); every extra day costs double-running and delays decommissioning.
- Match strictness — how tight the continuity criterion (to-the-cent versus a tolerance) and for how many clean cycles. Stricter is safer but can chase noise; too loose lets real defects through.
- Load fidelity — a full mirror of production versus a sample versus synthetic traffic. A full mirror is the truest test and the costliest.
- Cutover style — big-bang at the window's end versus staged by segment or cohort. Staged shrinks the blast radius but lengthens the double-run.
- Rollback horizon — how long the old configuration is kept warm after cutover. Longer preserves the escape hatch but delays reclaiming its cost and finishing the retreat.
When it helps, and when it misleads¶
Its strength is that it turns a terrifying switch into a monitored, reversible transition, proves continuity on real load rather than in rehearsal, and keeps a genuine fallback alive until the evidence justifies letting go.
Its failure mode is cost and comfortable limbo — two systems running indefinitely because no one will declare the criterion met, so the retreat never actually completes. And if the continuity criterion is weak or the parallel load is unrepresentative, a clean run gives false assurance and the defect surfaces only once the old configuration is gone. The classic misuse runs both ways: keeping the parallel run open as a security blanket, or cutting the window short under schedule pressure and calling an unproven system done. The discipline is to fix the continuity criterion and the cutoff conditions before the run starts, make the load representative, and hold to a pre-agreed maximum window so parallel operation ends in a decision, not a drift. This is a parallel run[1] — the standard migration and accounting practice of operating incumbent and successor together until the successor is trusted.
How it implements the components¶
parallel_operation_window— it defines and operates the bounded interval in which both configurations run live at once.continuity_criterion— it sets and checks the explicit match the successor must achieve on the functions that must not break, before cutoff.rollback_or_contingency_rule— by keeping the incumbent warm and recoverable, it preserves a live fallback and the rule for reverting if the successor fails.
It does not sequence which cohorts move when — that is the Migration Wave Plan — nor finally shut down and clear the old site, which is the Decommissioning and Restoration Runbook. It overlaps and proves; siblings order and close.
Related¶
- Instantiates: Managed Retreat — it is the low-risk cutover core, proving continuity before the old position is relinquished.
- Consumes: Receiving-Zone Reservation — the secured destination the new configuration runs against.
- Sibling mechanisms: Receiving-Zone Reservation · Retreat Trigger Exercise · Migration Wave Plan · Decommissioning and Restoration Runbook · Migration Readiness Assessment
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Parallel Site or System 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 the new configuration side by side long enough to move every dependency and prove continuity before the old one is cut off.
Independent corroboration: The frozen evidence defines Parallel Site or System Run as 'Runs the old and the new configuration side by side long enough to move every dependency and prove continuity before the old one is cut off', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Protocol, Workflow & Routine — Parallel Site or System 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: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Parallel Site or System 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 the new configuration side by side long enough to move every dependency and prove continuity before the old one is cut off.
Related originating lineages:
- Computer Science & Software Engineering — Parallel Site or System Run also draws materially on computer science and software engineering's formal and practical treatment of computation, interfaces, data, and reliable systems, which shaped this mechanism rather than merely adopting it as an application.
- Organizational & Management Science — Parallel Site or System 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: Both independent reviews agree on primary origin engineering_design; reconciliation resolves alternate_origin_disagreement. Formative alternate lineages retained: computer_science, organizational_management. The broader reach of later applications is kept separate as domain_reach=multi_domain; origin_mode=convergent records how the formative lineages relate. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=false preserves the reviewers' boundary judgment.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Because the retreat is not complete until cutoff, an open-ended parallel run keeps you in the very position you were trying to leave — paying to occupy the closing zone and the destination at once. The bounded window is therefore not a nicety but the thing that lets the run count as retreat rather than indefinite duplication.
References¶
[1] Public Sector Accounting Standards Board (Kenya). Guideline on Transition from Cash Basis to Accrual Basis of Accounting by Constitutional Commissions and Independent Offices. Public Sector Accounting Standards Board (2023). Describes parallel operation of old and new accounting systems during transition until the new system is sufficiently established. registry ↩