Technology Migration Plan¶
Migration plan — instantiates Creative Destruction Management
The program-level plan that justifies moving off an old platform and sequences the whole transition — dependencies mapped, a bounded dual-run window, and adoption tracked toward cutover.
A Technology Migration Plan is the program-level document that governs moving an entire technical platform to its successor. It answers the questions a single cutover procedure cannot: why the move is worth its disruption, what still depends on the old platform, how long the two systems will run side by side, and how we will know the new one is actually being taken up. Its defining move is sequencing under justification — it holds a live map of dependencies and a bounded coexistence window, and it advances the migration wave by wave only as adoption evidence accrues. It is the strategic wrapper that decides the order and pace of the transition; the concrete record-moving it delegates downward.
Example¶
A logistics company is moving its order and routing systems from an on-premises data center to a cloud platform. The plan opens with a value case: the data center's hardware refresh is due, capacity can't flex for peak season, and cloud elasticity plus managed services are projected to remove a class of 3 a.m. pages — enough benefit to justify a nine-month program of real disruption. Next comes a dependency and compatibility map: forty-one internal services, six partner EDI integrations, a warehouse-scanner fleet on hard-coded IP addresses, and two nightly batch jobs nobody remembers owning all still point at the old environment.
The plan then sequences the move in waves — stateless services first, the scanner fleet last — and opens a coexistence window in which old and new run in parallel behind a traffic splitter, so any wave can be shifted back if it misbehaves. Throughout, it watches adoption: percentage of traffic served from cloud, error rates per wave, and how many teams have cut their deploy pipelines over. When cloud traffic holds above 95% for two weeks with error rates at parity, the plan authorizes closing the window and decommissioning the data center. The plan never touched a single database row itself — it scheduled the runbooks that did.
How it works¶
- Lead with the value case, revisit it at each gate. The justification is not a one-time slide; if the projected benefit erodes as costs surface, the plan is designed to pause or descope rather than push on by momentum.
- Map dependencies before sequencing. The migration order is derived from the compatibility map — least-entangled first, most-depended-on last — so hidden couplings surface as plan risks, not production outages.
- Run the old and new in parallel behind a switch. A bounded coexistence window with a traffic splitter makes each wave individually reversible and lets validation happen under real load.
- Advance on adoption evidence, not calendar. Wave N+1 is authorized only when wave N's adoption and error signals clear declared thresholds.
Tuning parameters¶
- Wave granularity — one big cutover versus many small waves. Fine waves lower blast radius and give more adoption checkpoints but stretch the program and the cost of dual-running.
- Coexistence window length — how long parallel operation is funded. Longer is safer and more expensive, and risks normalizing permanent dual maintenance.
- Value-case hurdle — how much projected benefit must survive scrutiny before the next wave is funded. A high bar kills weak migrations early; too high stalls worthwhile ones.
- Adoption threshold for cutover — the traffic/error level that authorizes closing the window. Strict thresholds prevent premature decommissioning but can trap you in dual-run over a long tail of stragglers.
When it helps, and when it misleads¶
Its strength is holding a large, multi-team platform move together: it makes the justification explicit and revisitable, surfaces the dependencies that turn migrations into outages, and paces the transition on evidence rather than a fixed date. It is the antidote to the "launch the new thing and hope" failure the archetype warns against.
Its failure mode is the plan that quietly degrades into a lift-and-shift[n1] on paper while the value case rots underneath: waves slip, the coexistence window stretches, and the organization ends up paying to run both platforms indefinitely — permanent legacy drag with a Gantt chart. The classic misuse is treating adoption metrics as achievement — celebrating "80% traffic on cloud" while the remaining 20% is the mission-critical, hardest-to-move core that will decide whether the data center ever actually closes. The guarding discipline is to re-test the value case at every gate, put a hard end-condition (not just a date) on the coexistence window, and weight adoption signals toward the load-bearing users rather than the easy majority.
How it implements the components¶
replacement_value_case— states why the new platform is worth the disruption and what the old one cannot do, and gates each wave's funding on that case still holding.dependency_and_compatibility_map— inventories every service, integration, and device still bound to the old platform, and derives the migration order from it.coexistence_window— defines the bounded parallel-run period behind a traffic splitter within which waves are validated and reversible.adoption_signal— tracks traffic share, error parity, and team cutover as the evidence that authorizes advancing and, finally, decommissioning.
It does not execute the record-level extract/validate/cutover or its reversal (migration_path, rollback_or_contingency_rule) — those belong to its nearest twin, Data Migration Runbook, the executable procedure this plan sequences.
Related¶
- Instantiates: Creative Destruction Management — the program-level scaffold that justifies and sequences a platform replacement.
- Consumes: Data Migration Runbook — the plan schedules and depends on the runbook to perform each wave's actual data cutover.
- Sibling mechanisms: Data Migration Runbook · Deprecation Program · Infrastructure Replacement Program · Legacy Support Window · Policy Phase-Out Schedule · Product Sunset Plan · Stakeholder Transition Workshop · Workforce Transition Support
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Technology Migration Plan operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it the program-level plan that justifies moving off an old platform and sequences the whole transition — dependencies mapped, a bounded dual-run window, and adoption tracked toward cutover.
Independent corroboration: The frozen evidence defines Technology Migration Plan as 'The program-level plan that justifies moving off an old platform and sequences the whole transition — dependencies mapped, a bounded dual-run window, and adoption tracked toward cutover', so its operative form is Representation, Specification & Plan.
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: The defining operation is: The program-level plan that justifies moving off an old platform and sequences the whole transition — dependencies mapped, a bounded dual-run window, and adoption tracked toward cutover. In the computer_science lineage, that operation is specifically evidenced by authoritative or primary work that requires planned configuration transitions, dependency and baseline control, testing, authorization, and rollback. This makes computer_science the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: the program-level plan that justifies moving off an old platform and sequences the whole transition — dependencies mapped, a bounded dual-run window, and adoption tracked toward cutover.
- Operations Research — Operations research's allocation, scheduling, queueing, and optimization tradition provides a formative adjacent lineage for the same technology migration plan operation.
- Organizational & Management Science — Organizational design, management, and operational governance supplies a parallel or contributing lineage for the mechanism's defining operation: the program-level plan that justifies moving off an old platform and sequences the whole transition — dependencies mapped, a bounded dual-run window, and adoption tracked toward cutover.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science), so I adjudicated the mechanism rather than inheriting either label. The defining operation is: The program-level plan that justifies moving off an old platform and sequences the whole transition — dependencies mapped, a bounded dual-run window, and adoption tracked toward cutover. In the computer_science lineage, that operation is specifically evidenced by authoritative or primary work that requires planned configuration transitions, dependency and baseline control, testing, authorization, and rollback. This makes computer_science the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins. The cited NIST SP 800-128 Configuration Management directly supports the mechanism-specific operation and its disciplinary lineage. I retain all independently explained historical alternates without a numeric cap. origin_mode=cross_disciplinary_synthesis records how the mechanism arose; domain_reach=multi_domain separately records how broadly it can now be applied.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Lift-and-shift (or rehosting) is the industry term for moving a system to new infrastructure with minimal redesign. It is fast but often forfeits the very benefits that justified the move, which is why a migration plan's value case has to be re-tested rather than assumed once the mechanics are underway. ↩