Major Migration Approval Workflow¶
Approval workflow — instantiates Irreversible Commitment Management
Sequences a large one-way migration into approved waves, gating each wave behind rollback-residue assessment and accountable sign-off so the whole system is never cut over at once.
A Major Migration Approval Workflow governs the big, one-way move — a data-center migration, a core-system replacement, a re-platforming — by refusing to let it happen as a single all-or-nothing cutover. Its defining shape is a multi-step, multi-approver process: the migration is broken into ordered waves (by tenant, region, data class, or subsystem), and each wave carries its own accountable sign-off and its own check of what a rollback would leave behind. It is not a single gate check and not a live-traffic technique; it is the governance spine that decides who authorizes each irreversible step and in what order, so that the first real move is small, reversible-enough, and owned by a named approver rather than triggered by whoever happened to run the script.
Example¶
A bank is retiring a thirty-year-old mainframe ledger and moving to a new core banking platform — an irreversible cutover, because once accounts transact on the new system the old ledger's state diverges and cannot be reconciled backward. Rather than a weekend "big bang," a major migration approval workflow sequences it: first internal test accounts, then employee accounts, then a single low-volume branch, then regions in waves, in the spirit of a strangler-fig migration that replaces a legacy system incrementally[1].
Each wave is its own gate. Before employee accounts move, an owner signs off that the wave's scope and readiness are acceptable; a rollback-residue assessment confirms what could and could not be recovered if the wave failed (posted transactions cannot be un-posted, so a per-wave reconciliation snapshot is required). Approval to proceed to the next wave is contingent on the prior wave's clean close. No single person can flip the whole bank at once, and the point of first irreversible commitment is a handful of internal accounts, not ten million customers.
How it works¶
- Decompose into ordered waves. Slice the migration by tenant, region, data class, or subsystem so commitment is sequential, not system-wide, and early waves are the least risky.
- Assign accountable sign-off per wave. Each wave has a named approver who authorizes crossing that wave's threshold, matching authority to the consequence being imposed.
- Assess rollback residue per wave. Before each wave, enumerate what would not be recoverable if it failed, and require the compensating preconditions (snapshots, reconciliation exports).
- Gate progression on prior-wave close. Advancing is conditional on the previous wave completing cleanly, so problems halt the sequence before they compound.
Tuning parameters¶
- Wave granularity — many small waves versus a few large ones. Finer waves shrink each irreversible step but stretch the timeline and multiply sign-offs; coarser waves move faster but raise per-wave stakes.
- Approval seniority — how senior the sign-off must be per wave. Higher seniority strengthens accountability but bottlenecks throughput and invites rubber-stamping.
- Advancement criteria — what "clean close" requires before the next wave (error budget, reconciliation, soak time). Strict criteria catch trouble early but slow the rollout.
- Backout provisioning — how much per-wave recovery scaffolding (snapshots, dual-write, reconciliation) is mandated. More scaffolding softens each crossing but adds engineering cost and can itself introduce drift.
When it helps, and when it misleads¶
Its strength is that it makes a system-wide irreversible move accountable and ordered: the blast radius of a mistake is one wave, the authority to commit is explicit and named, and the sequence can be halted between waves before a small failure becomes a total one. It is the right structure whenever the migration is indivisible in outcome but divisible in execution.
Its failure mode is process without teeth: sign-offs become rubber stamps, waves are scheduled so tightly there is no real halt-and-learn between them, and "approved" ceases to mean "assessed." A subtler trap is early waves that are unrepresentative — internal accounts that never exercise the paths where the real migration breaks — giving false confidence before the hard wave. The discipline is to make each sign-off contingent on the prior wave's evidence, choose early waves that actually stress the risky paths, and keep genuine authority (and a genuine stop) at each gate rather than a schedule that only moves forward.
How it implements the components¶
staged_commitment_path— it is the wave sequencing: the migration is committed in ordered slices, never as one system-wide cutover.consent_or_review_gate— each wave carries a named, accountable sign-off authorizing that step's irreversible commitment.rollback_residue_assessment— before each wave, what would not survive a failed cutover is enumerated and its compensating preconditions required.
It sequences commitment by governance approval; it does not cap *live production blast radius through automated exposure_limit + impact_monitoring_signal — that traffic-shaping is Staged Rollout or Canary Release, its nearest twin — nor is it the single binary point_of_no_return_marker checkpoint of Irreversible Deployment Gate.*
Related¶
- Instantiates: Irreversible Commitment Management — supplies accountable, wave-by-wave governance for a large one-way migration.
- Consumes: Irreversible Deployment Gate can serve as the per-wave residue checkpoint inside the workflow.
- Sibling mechanisms: Staged Rollout or Canary Release · Irreversible Deployment Gate · Sandbox Simulation or Pilot · Destructive Action Confirmation · Remediation or Compensation Plan
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Major Migration Approval Workflow operates as a repeatable ordered procedure or handoff sequence that coordinates action because it sequences a large one-way migration into approved waves, gating each wave behind rollback-residue assessment and accountable sign-off so the whole system is never cut over at once.
Independent corroboration: The frozen evidence defines Major Migration Approval Workflow as 'Sequences a large one-way migration into approved waves, gating each wave behind rollback-residue assessment and accountable sign-off so the whole system is never cut over at once', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Incremental replacement, wave migration, rollback, and reconciliation originate in software and information-systems engineering.
Related originating lineages:
- Accounting & Auditing — Control assurance contributes maker-checker sign-off and evidence of readiness for consequential cutovers.
- Organizational & Management Science — Accountable gates and wave approvals materially supply the high-consequence change-governance layer.
Review resolution: Both independent reviews assign primary provenance to computer_science. The queued secondary differences (alternate_origin_disagreement, domain_reach_disagreement, encyclopedia_synthesis_disagreement) are reconciled by retaining accounting_auditing, organizational_management only as formative or independently established lineage(s), not merely as application domains. origin_mode=cross_disciplinary_synthesis records the provenance relationship, while domain_reach=multi_domain separately records applicability breadth. confidence=high preserves the more cautious assessment, and encyclopedia_synthesis=true records whether either reviewer identified a corpus-specific synthesis.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Fowler, M. "Original Strangler Fig Application" (29 June 2004). Describes gradual strangler-fig replacement of a legacy system from its edges. registry ↩