Merge and Deprecation Plan¶

Consolidation-and-sunset plan — instantiates Opportunity-Gated Adaptive Diversification

A sequenced plan for consolidating the surviving branches and retiring the obsolete ones once a space has been explored, preserving what the pruned lines learned.

Diversification that never ends becomes its own pathology — permanent pilot sprawl, fragmented infrastructure, a dozen half-supported branches no one will kill. Merge and Deprecation Plan is the mechanism that closes the cycle. Once selection has decided which lines win, this plan sequences the actual work of folding survivors together and sunsetting the rest: what merges into what, in what order, with what migration path, and how the obsolete branches are retired without losing what they taught. Its defining move is that it operates after the choice is made — it is not a decision artifact but an execution one, turning "we're keeping A and B and dropping the rest" into a safe, ordered, reversible dismantling.

Example¶

A media group spent three years letting each of its acquired titles keep its own content-management system while the right platform was unclear — a deliberate, opportunity-gated proliferation as it learned what a modern newsroom actually needs. Five systems now run in parallel; two clearly dominate. The Merge and Deprecation Plan sequences the wind-down. It sets an explicit prune rule — a system is deprecated once its last active title has a supported migration path onto a survivor — and orders the steps: freeze new title onboarding onto the three losers, publish migration runbooks, set a sunset date roughly two quarters out, then decommission.

Crucially, it doesn't just switch off the losing systems. It captures their provenance first — the editorial workflows, the odd archival formats, the reasons a survivor doesn't yet handle a niche feature one title depended on — so the merge inherits their hard-won lessons instead of rediscovering them live. The outcome is a consolidated platform, a clean sunset calendar, and an archived record that makes the pruning reversible if a "loser" turns out to have covered a workflow the survivors miss.

How it works¶

Take the selection as given. Start from an already-made keep/cut decision — this plan executes it rather than re-arguing it.
Define the prune rule and its guard. State the explicit condition under which a branch is retired, and the precondition (a migration path, a covered dependency) that must hold before the cut lands.
Sequence the consolidation. Order the merges and sunsets — freeze, migrate, sunset, decommission — so nothing is dropped before its users and dependencies have somewhere to go.
Preserve provenance. Archive each retired branch's rationale, edge cases, and lessons so the survivors inherit them and the cut stays reversible.

Tuning parameters¶

Sunset horizon — how long between deprecation notice and decommission. Long horizons ease migration but prolong the fragmentation you're trying to end.
Prune aggressiveness — how strong the case must be before a branch is cut. Aggressive pruning consolidates fast but risks killing a line that quietly covered a real niche.
Migration support level — from a bare guide to hands-on porting. More support lowers the pain and resistance of a merge but costs the surviving team dearly.
Provenance depth — how much of a retired branch is archived, from a one-line reason to full design records. Deeper archives make reversal real but take effort to capture.
Reversibility window — how long a deprecated branch can still be reactivated before it's truly gone. A longer window is insurance against a premature cut.

When it helps, and when it misleads¶

Its strength is that it makes stopping a first-class, planned activity rather than an afterthought — the single hardest and most-skipped move in any diversification, and the cure for permanent pilot sprawl. By preserving provenance, it lets an organisation consolidate without amnesia, and by keeping cuts reversible for a window, it lowers the stakes of pruning.

Its failure modes cut both ways. Deprecate too early and you amputate a branch that was covering a niche the survivors don't — the plan should always be checked against a coverage view before it lands. Deprecate too late, or never, and the "plan" becomes a document that legitimises endless sprawl. The classic misuse is running it as cover for a political kill — writing the deprecation plan to retire a rival's project under the language of consolidation, provenance conveniently un-captured. The guard against this is a stated, evidence-based prune rule and a real reversibility window, so a cut can be defended and, if wrong, undone — the opposite of quietly escalating a commitment no one will revisit.^[1]

How it implements the components¶

Merge and Deprecation Plan realises the consolidation-execution side of the archetype — the components that carry out an already-made pruning decision:

consolidation_pathway — it sequences how surviving branches merge and how users and dependencies migrate onto them.
exit_or_prune_rule — it states the explicit condition, and its guard, under which an obsolete branch is retired.
provenance_trace — it archives each pruned branch's rationale and lessons so the merge inherits them and the cut stays reversible.

It executes a decision it does not make — the criteria and scoring that choose what survives (niche_fit_criterion, selective_retention_rule) belong to Multi-Criteria Selection Rubric — and it consolidates rather than mixes live lineages (recombination_interface — that's Network Mixing Protocol).

Instantiates: Opportunity-Gated Adaptive Diversification — this plan is how the archetype ends proliferation and consolidates without losing what was learned.
Consumes: the keep/cut decision from Multi-Criteria Selection Rubric and the fate calls of Preserve–Prune–Recombine Review, which it turns into sequenced action.
Sibling mechanisms: Multi-Criteria Selection Rubric · Innovation Portfolio Review · Network Mixing Protocol · Diversity Coverage Matrix · Diversity-Floor Rate Boost · Experimental Cohort Split · Parallel Pilot Trials · Protected Pilot Lane · Stage-Gate Exploration · Lineage–Niche Fit Dashboard · Niche Portfolio Matrix · Opportunity Landscape Mapping · Preserve–Prune–Recombine Review · Saturation and Crowding Review · Specialization Cohort Seeding

References¶

[1] Escalation of commitment — the tendency to keep pouring resources into a failing course because of what's already sunk into it — is the pathology a reversible, rule-based deprecation plan is meant to break, provided the plan is used to test a decision rather than to rationalise one already made. ↩