Skip to content

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 — the standard migration and accounting practice of operating incumbent and successor together until the successor is trusted.[1]

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.

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] A parallel run is the established practice — in system migration and in accounting-system changeovers — of operating the incumbent and its successor concurrently on the same live inputs until the successor's outputs are trusted, at which point the incumbent is retired. ↩