Benefit-Preserving Transition Plan¶
Workflow — instantiates Workaround Governance
A staged migration that supplies the workaround's legitimate function through a safer route before the deviation is restricted or removed.
Most attempts to shut down a workaround fail because they subtract the deviation without first replacing the thing it was quietly doing. A Benefit-Preserving Transition Plan inverts that order: it treats removal as the last step, not the first. Its defining commitment is a named, testable legitimate function — the speed, continuity, access, or safety the workaround supplied — that must be demonstrably available through the new route before the old one is throttled. The plan is a sequence, not a switch: build the replacement, prove it under real load, migrate users onto it, keep a fallback live, and only then retire the deviation. Everything else the plan does exists to protect that one guarantee — that nobody loses the function on the day the workaround goes away.
Example¶
At a regional hospital, nurses on the night shift routinely drop out of the electronic medication administration record (eMAR) and onto a paper "downtime form" whenever the system lags during the 2 a.m. medication pass — the lag is real, and the paper route keeps patients medicated on time. Governance has decided to eliminate the paper route because it creates reconciliation gaps, but the transition plan refuses to pull it on a fixed date. Instead it sequences the change: the vendor ships a lightweight offline-cache mode; the plan pilots it on two units for a full month across peak and exception cases; it trains staff on the new fast path; it runs the cache mode and paper form in parallel so a cache failure still has a fallback; and it defines the retirement trigger as "zero missed-dose events attributable to lag over four consecutive weeks," not a calendar date. Only when the new route demonstrably carries the 2 a.m. load does the paper form get pulled — and the plan checks explicitly that per-diem float nurses, who rotate across units and never learned the workaround, are no worse served by the new route than the regulars were by the old one.
How it works¶
The plan's spine is the ordering discipline, plus two things generic migrations skip:
- Name the function before you touch the route. The transition opens by writing down what outcome the workaround delivers and to whom — stated as a condition the replacement must meet, not a vague benefit.
- Sequence build → validate → migrate → retire. New capability first; realistic validation (peak load, exception cases, the awkward edges the workaround handled) before any user moves; migration with training; retirement of the deviation last.
- Keep a live fallback across the cutover. A rollback path stays available until the new route has proven itself, so the cutover is reversible rather than a leap.
- Gate retirement on evidence, not on a date. The trigger to pull the workaround is a measured outcome ("the function is now carried"), which is what separates this from a mandated deadline.
- Check who the new route leaves out. Before retirement, confirm the replacement serves the people who never used the workaround as well as those who did — the transition must not quietly re-sort who gets served.
Tuning parameters¶
- Cutover style — big-bang versus phased rollout. Phased limits blast radius and buys evidence but stretches the parallel-run cost; big-bang is cheaper to run but bets everything on one day.
- Parallel-run length — how long the old and new routes coexist. Longer is safer and more expensive, and if it never ends you have simply legitimized the workaround.
- Retirement trigger — calendar date versus evidence threshold. An evidence gate protects the function but can slip indefinitely if the threshold is set unreachably high.
- Fallback retention — how long the rollback path stays armed after cutover. Keeping it longer hedges failure but tempts users to keep drifting back.
- Access-coverage bar — whether "the function is preserved" means for the median user or for the worst-served group; a stricter bar catches exclusion but delays cutover.
When it helps, and when it misleads¶
Its strength is that it makes elimination safe to attempt: because the function is carried before the deviation is cut, the organization can retire an unsafe practice without the recoil that normally drives people into a new, more hidden workaround. It converts "stop doing that" into "here is the better way, proven, and now the old way ends."
Its central failure mode is cutting before the replacement actually delivers — declaring victory when the new route works in a demo but not at 2 a.m. under load, so the function silently degrades and staff quietly rebuild the old path off the books. The classic misuse is a date-driven cutover imposed by a program deadline rather than by evidence, which removes the workaround while the pressure that created it is still fully present. The guarding discipline is Chesterton's fence[1]: never take the deviation down until you can articulate, and have measured, exactly what it was doing — and keep the fallback armed until that measurement holds.
How it implements the components¶
This workflow fills the function-and-access side of the disposition — the part that makes removal survivable:
benefit_preservation_requirement— the plan's opening act is naming the legitimate function as a condition the replacement must meet, and every downstream step exists to keep that function continuously available across the cutover.equity_and_access_impact_check— before retirement the plan verifies the new route serves the people who never used the workaround (float staff, newcomers, adjacent teams) at least as well, so the migration does not re-sort access.
It does not fund or design the fix to the underlying source condition (formal_system_repair_link — that is Linked Root-Cause Repair Ticket), nor authorize the interim continuation while the transition runs (provisional_authorization_envelope — that is Temporary Deviation Permit).
Related¶
- Instantiates: Workaround Governance — this workflow executes the "preserve the legitimate function" invariant during a replace-or-eliminate disposition.
- Consumes: Linked Root-Cause Repair Ticket — supplies the repaired capability the transition migrates onto.
- Sibling mechanisms: Linked Root-Cause Repair Ticket · Multi-Path Disposition Matrix · Nonpunitive Workaround Review · Practitioner Counterfactual Walkthrough · Recurrence and Displacement Dashboard · Structured Workaround Registry · Temporary Deviation Permit · Workaround Failure-Mode and Effects Review · Sunset and Reauthorization Review
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: A staged migration that supplies the workaround's legitimate function through a safer route before the deviation is restricted or removed, making its operative form an enacted repeatable sequence of actions, handoffs, or states.
Independent corroboration: The frozen evidence defines Benefit-Preserving Transition Plan as 'A staged migration that supplies the workaround's legitimate function through a safer route before the deviation is restricted or removed', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Change-management practice sequences replacement capability, validation, migration, fallback, and retirement so a workaround's legitimate function survives the transition.
Related originating lineages:
- Computer Science & Software Engineering — Parallel-change migrations keep the old path available until the replacement carries its legitimate function.
- Engineering & Design — Controlled cutovers and temporary works preserve service while a safer configuration is introduced.
- Public Administration & Policy — Policy transitions use grandfathering, bridging support, and staged withdrawal to preserve legitimate benefits.
Review resolution: Organizational management is the agreed primary lineage through staged change and continuity planning. Software parallel change, engineering cutovers, and policy transitions independently preserve function while retiring an unsafe workaround; reach is multi-domain, not literally universal.
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] Chesterton, G. K. The Thing: Why I Am a Catholic. Sheed & Ward (1929). Argues that an institution should not be removed until the reformer can explain its use. registry ↩