Migration Acceptance Test¶
A migration-gate procedure — instantiates Correspondence Validation
Uses agreed acceptance criteria to decide whether a migration may proceed, pause, roll back, or remain limited to a subset of cases.
A Migration Acceptance Test is the whole-migration go/no-go gate. It takes the assembled correspondence evidence — reconciliation results, classified divergences, coverage — measures it against acceptance criteria and a tolerance band fixed before the results were seen, and returns a governance verdict: proceed with cutover, pause, roll back, or limit the migration to the subset of cases that actually reconciled. Its defining move is that it decides at the level of the migration, not the individual mismatch, and it binds that decision to rollout: until the criteria are met, the migration cannot advance, and it may be pinned to a validated scope while the rest stays on the old system. It produces no evidence and classifies nothing; it is the pre-committed rule that turns evidence into an authorized action.
Example¶
A national retailer is moving all sales reporting from a legacy data warehouse to a new lakehouse. Before the old warehouse can be retired, a Migration Acceptance Test governs the cutover. The criteria are agreed in advance with finance: daily gross revenue, unit counts, and customer-cohort tallies must reconcile between the two systems to within ±0.1% across a defined set of 40 canonical reports, spanning a full fiscal month including quarter-end, with zero unreconciled variance on any regulated financial figure. The reconciliation is run; 37 reports clear the tolerance band cleanly. Two loyalty-cohort reports drift by 0.6% because of a timezone boundary in the new pipeline, and one tax report has an unexplained variance. The verdict is not "good enough, ship it." It is limit: the 37 clean reports cut over, the loyalty and tax reports stay on the legacy warehouse behind the guardrail, and the tax variance blocks any further scope expansion until it is explained. The gate converted evidence into a scoped, defensible transition instead of a hopeful all-or-nothing switch.
How it works¶
- Pre-register the criteria and tolerance band. The pass condition — which figures must match, how closely, over what cases and calendar — is agreed before results exist, so the bar can't be moved to fit the outcome.
- Read the assembled evidence. Reconciliation output and classified divergences come from comparison and review mechanisms; the gate consumes them.
- Evaluate against the bar. Within tolerance and no blocking-class divergence → proceed; otherwise pause, roll back, or narrow.
- Bind the verdict to rollout. The guardrail holds cutover behind the gate and can pin the migration to the reconciled subset, keeping the old system authoritative for everything unvalidated.
- Re-gate on every scope expansion. Each stage or added case set re-runs the test rather than inheriting an earlier pass.
Tuning parameters¶
- Tolerance-band width — how much old/new disagreement still counts as a match. Tight bands catch subtle regressions but stall on benign noise; loose bands ship faster but hide drift.
- Blocking-class policy — which divergence classes veto the gate outright (e.g. any regulated-figure mismatch) versus which are merely noted. Stricter policy protects high-stakes cases at the cost of throughput.
- Scope granularity — all-or-nothing cutover versus per-report acceptance. Granular gating enables partial, safer migration but multiplies bookkeeping.
- Rollback-trigger sensitivity — how much post-cutover divergence reopens the gate and reverts. Sensitive triggers protect users but risk thrashing on transient noise.
- Re-gate cadence — whether every scope expansion re-tests or a prior pass carries forward, trading assurance against speed.
When it helps, and when it misleads¶
Its strength is that it converts "are we ready to cut over?" from a nervous judgment call into a pre-committed, checkable rule, and its bind-to-rollout design makes compatibility theater impossible at the migration level — evidence that fails the bar actually stops the migration. Because it can limit rather than reject, it naturally supports staged, partial cutover under a go/no-go poll[n1] rather than a single risky switch.
Its failure mode is a gate calibrated to always open: a tolerance band set wide enough that nothing ever fails, or criteria quietly relaxed after the results arrive to hit a deadline, which restores the very go-by-nerve it was meant to replace. The classic misuse is moving the goalposts — redefining "acceptable" once the reconciliation comes back ugly. The guarding discipline is to fix the criteria and tolerance in advance with the stakeholders who bear the regression cost, keep a live rollback path so proceed is reversible, and treat any post-registration loosening of the bar as an exception that itself requires sign-off.
How it implements the components¶
The gate-and-rollout core of the archetype — the components a decision procedure owns:
acceptance_or_limitation_decision— it is the verdict: proceed, pause, roll back, or limit the migration to the validated subset; this is the component that turns validation into governance.migration_guardrail— it holds rollout behind the gate, keeping the old system authoritative until criteria are met and pinning the migration to the reconciled scope.tolerance_band— it defines and applies the pre-agreed band of acceptable old/new disagreement that the verdict is computed against.
The gate reads divergences but does not classify or log them — divergence_classification and the exception_register are Divergence Review Workflow, its nearest twin (the workflow sentences each mismatch; this gate decides the migration on the sentenced pile); and it does not run the behavior_comparison that produces the reconciliation it reads — that is Protocol Conformance Test (and, on live traffic, Shadow Run or Parallel Run).
Related¶
- Instantiates: Correspondence Validation — it is the acceptance gate that binds correspondence evidence to an authorized transition.
- Consumes: Divergence Review Workflow supplies the classified divergences it weighs, and Shadow Run or Parallel Run supplies the reconciliation evidence.
- Sibling mechanisms: Divergence Review Workflow · Model-Limit Validation · Protocol Conformance Test · Backward Compatibility Test · Golden Case Benchmark · Regression Test Suite · Shadow Run or Parallel Run
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Migration Acceptance Test operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it uses agreed acceptance criteria to decide whether a migration may proceed, pause, roll back, or remain limited to a subset of cases.
Independent corroboration: The frozen evidence defines Migration Acceptance Test as 'Uses agreed acceptance criteria to decide whether a migration may proceed, pause, roll back, or remain limited to a subset of cases', so its operative form is Decision, Gate & Allocation.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Go, pause, rollback, and limited-release acceptance criteria arise in software and data migration practice.
Related originating lineages:
- Engineering & Design — Commissioning and acceptance testing provide an older systems-transition assurance lineage.
- Organizational & Management Science — For Migration Acceptance Test, coordination, governance, strategy, process design, and management-control practice materially shaped the mechanism's characteristic form.
Review resolution: Both independent reviews place the primary provenance in computer_science. The queued differences (alternate_origin_disagreement, domain_reach_disagreement) concern secondary metadata, not primary lineage. The final retains engineering_design, organizational_management only where a reviewer supplied a formative-lineage rationale; downstream use or broad applicability by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis because the supplied rationales identify formative contributions that are composed in the mechanism's present form. domain_reach=multi_domain records established application breadth separately from provenance. confidence=high preserves the more cautious evidence assessment. encyclopedia_synthesis=false records whether either reviewer identified deliberate corpus-level composition.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A go/no-go decision is the pre-launch poll used in flight and mission operations, where each responsible party declares "go" or "no-go" against agreed criteria before commit, and any single "no-go" holds the launch. It is the canonical example of a gate whose criteria are fixed in advance precisely so they cannot be softened under the pressure of the moment. ↩