Stovepipe Retirement Migration Plan¶
Workflow — instantiates Shared-Input Variety Platform Design
Migrates duplicated vertical stacks into a shared layer when the scope benefit exceeds migration and coupling costs.
A Stovepipe Retirement Migration Plan is a phased workflow that consolidates existing duplicated vertical stacks into the shared layer — but only where the measured scope benefit exceeds the migration and new-coupling cost — and sequences the cut-over so that concentrating many outputs onto one shared component does not create an unbounded blast radius. Its defining move is retiring legacy duplication already in production, gated on net benefit and paced to control coupling. It operates on the installed base — the stacks that already exist and already work — which is what makes it a migration problem rather than a design one: the shared destination must be reached without breaking the outputs that currently depend on the duplicates.
Example¶
A healthcare provider network, assembled through mergers, runs three separate patient-scheduling systems inherited from three acquired hospital groups, plus duplicated lab-order stacks. Leadership wants "one platform," and the tempting move is a big-bang cut-over. But scheduling outages harm patients, so a reckless consolidation is worse than the duplication.
The plan proceeds in stages. First, the benefit metric confirms per stack that consolidation actually nets out positive: scheduling clearly does; the lab-order duplication, surprisingly, does not yet clear the bar, so it is deferred rather than forced. Then scheduling is migrated one hospital group at a time — pilot first, old and new run in parallel, and the coupling-risk register is watched closely, because one shared scheduler now serving every site has a far larger blast radius, so redundancy is added before the next group cuts over. Outcome: duplication is retired incrementally where it pays, correlated-failure risk is managed as concentration rises, and the negative-benefit consolidation is wisely left alone.
How it works¶
- Inventory the duplicated stacks and gate each on net benefit — consolidate a stack only where its scope benefit beats the migration plus new-coupling cost; defer or skip the rest.
- Sequence the migration (pilot → wave → cut-over), running old and new in parallel through each step so a failure is recoverable.
- Track rising coupling. Each consolidation increases concentration; the plan updates the coupling register and adds redundancy or blast-radius limits before raising concentration further.
- Decommission only after proof. The retired stack is switched off only once the shared layer has carried its load in production.
Tuning parameters¶
- Migration pacing — big-bang versus incremental cut-over. Fast is cheaper if it works and catastrophic if it doesn't; incremental costs more but bounds the damage.
- Benefit hurdle — how much net benefit a stack must show before it is migrated at all; a high hurdle spares marginal consolidations.
- Parallel-run duration — how long old and new coexist. Longer is safer but doubles running cost during the overlap.
- Cut-over granularity — per-site, per-function, or all-at-once switching; finer granularity limits blast radius per step.
- Rollback readiness — how quickly a failed cut-over can revert, which sets how aggressively the plan can move.
When it helps, and when it misleads¶
Its strength is turning "consolidate everything" zeal into a benefit-gated, risk-paced retirement that actually lands — and, crucially, that knows when not to consolidate, leaving a duplicate in place when its migration would not pay. It converts a dangerous portfolio-wide rip-and-replace into a sequence of recoverable steps.
Its failure mode is a big-bang cut-over that takes down multiple outputs at once because coupling was concentrated faster than it was safeguarded, or a forced consolidation of a stack whose net benefit never justified it — the benefit gate mis-set or ignored under pressure to "finish the platform." The classic misuse is migrating for tidiness or optics rather than measured benefit. The guarding discipline is to gate every migration on the benefit metric, stage the coupling, and replace legacy incrementally with a strangler-fig[n1] cut-over rather than a big bang.
How it implements the components¶
scope_benefit_metric— each stack is migrated only when consolidation's benefit exceeds its migration and coupling cost; the metric is the go/defer gate.common_capability_layer— the migration's destination is the shared layer, into which the existing duplicated stacks are folded.coupling_risk_register— because consolidation raises concentration, the plan tracks and bounds the growing blast radius, adding redundancy before each cut-over.
It does not screen a single new output's fit at entry (reuse_onboarding_path, variation_boundary, local_fit_exception_path — that is its nearest twin Reuse Intake and Fit Assessment); the retirement plan consolidates existing duplicate stacks in bulk, whereas intake decides one new arrival's fit at the door.
Related¶
- Instantiates: Shared-Input Variety Platform Design — this plan is how a portfolio's pre-existing stovepipes are retired into the shared layer.
- Consumes: Cross-Output Cost Attribution Model supplies the per-stack net-benefit figure that gates each migration.
- Sibling mechanisms: Common Platform Roadmap · Cross-Output Cost Attribution Model · Joint Procurement or Tooling Pool · Modular Capability Library · Platform Governance Board · Product-Line Architecture · Reuse Intake and Fit Assessment · Shared Data or Feature Store · Shared Service Catalog
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Stovepipe Retirement Migration Plan is defined in the frozen evidence as: Migrates duplicated vertical stacks into a shared layer when the scope benefit exceeds migration and coupling costs. Its operative deployed or enacted form is therefore Representation, Specification & Plan.
Nearest alternative: Protocol, Workflow & Routine — Protocol, Workflow & Routine can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Retiring isolated systems through target architecture, dependency mapping, staged migration, and decommission criteria is enterprise-architecture modernization. GAO guidance treats architecture as the transition plan from fragmented current systems to an integrated target; management and governance supply ownership and sequencing.
Related originating lineages:
- Economics & Finance — Scope benefit must exceed migration cost.
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: migrates duplicated vertical stacks into a shared layer when the scope benefit exceeds migration and coupling costs.
- Organizational & Management Science — Silos and owners must transition.
- Public Administration & Policy — public_administration_policy contributes public administration, policy implementation, and program oversight to this mechanism's defining operation—Migrates duplicated vertical stacks into a shared layer when the scope benefit exceeds migration and coupling costs—without displacing the selected primary historical lineage.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: migrates duplicated vertical stacks into a shared layer when the scope benefit exceeds migration and coupling costs.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus organizational_management). Authoritative or primary research supports computer_science as the best historical origin: Retiring isolated systems through target architecture, dependency mapping, staged migration, and decommission criteria is enterprise-architecture modernization. GAO guidance treats architecture as the transition plan from fragmented current systems to an integrated target; management and governance supply ownership and sequencing. The cited U.S. GAO, Organizational Transformation: A Framework for Assessing and Improving Enterprise Architecture Management; U.S. GAO, Information Technology: Architecture Needed to Guide Modernization of DOD's Financial Operations directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records lineage, while domain_reach=multi_domain records later applicability separately from provenance.
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:
- U.S. GAO, Organizational Transformation: A Framework for Assessing and Improving Enterprise Architecture Management
- U.S. GAO, Information Technology: Architecture Needed to Guide Modernization of DOD's Financial Operations
Notes¶
[n1] Strangler fig pattern — Martin Fowler's term for incrementally replacing a legacy system by routing functions one at a time to the new one until the old can be switched off, named after the vine that gradually envelops its host tree. It is the low-risk alternative to a big-bang migration when the stacks being retired are in live use. ↩