Skip to content

Migration Readiness Assessment

Stage-gate readiness review — instantiates Managed Retreat

A pre-stage go/no-go check that a tested fallback exists and every continuity provision is in place, so a cohort commits to moving only when it could still safely turn back.

A Migration Readiness Assessment is the gate each retreat stage must pass before it is allowed to proceed. Its defining question is not should we retreat? — a strategic trigger settles that — but are we actually ready to move this cohort now, and could we reverse it if the move went wrong? It verifies two things above all: that a tested rollback or contingency is standing by, and that the continuity provisions the move depends on (data and state transfer, service handoff, records, authority) are genuinely in place rather than merely promised. It turns "we think we're ready" into a checkable pass/fail that stops a premature move from becoming an irreversible one.

Example

A hospital is relocating, ward by ward, out of a flood-prone wing into a new building over eighteen months. Before each ward moves, its Migration Readiness Assessment runs down a fixed list: is the new ward commissioned and its records fully mirrored; is there a tested fallback — can this ward run in the old wing for another week if the new one fails on the day; are on-call staff, pharmacy links, and the patient-transfer protocol confirmed. The oncology ward passes first time. The intensive-care ward fails: the rollback exists on paper but has never been rehearsed, and one monitoring integration is unverified. Its move is held two weeks until both are demonstrated — not because the retreat is in doubt, but because ICU is exactly the cohort you must be able to turn back. The assessment says nothing about which ward should move first; it only says whether the next one is safe to release.

How it works

  • Fix the checklist before pressure. The prerequisites — rollback tested, continuity confirmed, authority present — are agreed in calm conditions so they cannot be quietly relaxed under deadline.
  • Demand demonstration, not assertion. Each item is shown to work — the rollback rehearsed, the state transfer verified — rather than ticked because someone is confident.
  • Return a binary release. The output is go / hold for this stage, with the specific failed items named, not a soft score that invites rounding up.
  • Re-run per stage. Readiness is checked afresh for every cohort, because a wing that was ready last month may not be after the corridor or destination changed.

Tuning parameters

  • Bar height — how much proof each prerequisite demands. A high bar prevents unsafe moves but can stall the retreat against the closing horizon; too low and the gate becomes a rubber stamp.
  • Rollback horizon — how long a fallback must remain viable after the move. Longer is safer but holds the old position (and its cost) open longer.
  • Scope of the check — which prerequisites are in scope: continuity, capacity, authority, support. Wider catches more failure modes; narrower is faster but blinder.
  • Waiver policy — whether, and by whom, a failed item can be waived. Tight waivers protect integrity; loose ones let schedule pressure override the gate.
  • Re-assessment trigger — what change forces a re-run — a new corridor, a slipped date. Sensitive re-triggering keeps the verdict current; insensitive saves effort but risks acting on a stale pass.

When it helps, and when it misleads

Its strength is that it keeps an orderly retreat from turning into an irreversible lurch: by refusing to release a cohort that cannot fall back or cannot preserve continuity, it converts nerve and optimism into evidence. It also localizes failure — a hold names the exact missing provision, so the fix is targeted rather than a general delay.

The gate is only as honest as its bar, and under schedule pressure that bar tends to erode one small exception at a time — the pattern of normalization of deviance, where each relaxed criterion looks reasonable until the accumulated slack fails.[1] Its classic misuse is running it backwards: convening the review to bless a move-date already fixed, waiving whatever fails, so the assessment launders a decision instead of testing it. The guard is a pre-agreed bar, demonstrated (not asserted) evidence, and waivers that are logged and rare.

How it implements the components

  • rollback_or_contingency_rule — its core precondition: it requires a tested fallback to exist and stay viable before a stage is released.
  • continuity_criterion — it verifies that the continuity provisions the move depends on (state transfer, handoff, records, authority) are demonstrably in place, treating any unconfirmed one as a hold.

It confirms continuity is ready but does not itself keep services running across the cut — overlapping operation to preserve continuity is Parallel Site or System Run. It also does not order the cohorts (that's Migration Wave Plan) or fund the move (that's Transition Support Plan).

Notes

The assessment gates readiness to move, not the decision to retreat: the strategic go/no-go is the Retreat Trigger, and this gate assumes it has already fired. Confusing the two lets a team endlessly "assess readiness" as a way to avoid committing to the retreat at all — the gate should sharpen an approved move, never substitute for the trigger.

References

[1] Normalization of deviance — Diane Vaughan's term for how repeatedly accepting a small out-of-spec condition makes it come to seem normal, until the accumulated exceptions contribute to failure. It is the standard name for how a readiness bar quietly erodes under schedule pressure. ↩