Legacy Support Window¶
Support protocol — instantiates Creative Destruction Management
A bounded protocol that keeps the old path alive at a defined, shrinking service level for a set time — enough support to migrate safely, with a declared date the window closes.
A Legacy Support Window is the protocol that governs how much support the old path keeps receiving, and for how long, while dependents move away. Its defining commitment is a defined, declining service level with a fixed end: the incumbent is not abandoned and not maintained forever — it is held at a specified tier (often shrinking from full support, to fixes-only, to security-only) for a bounded period whose closing date is announced up front. It answers the question the rest of the transition leans on: "if I haven't moved yet, exactly what will still work, how well, and until when?" It is a promise about the old thing's remaining life, precise enough to plan a migration around and bounded enough that it cannot quietly become permanent.
Example¶
A mobile operating-system vendor releases a major new version and must decide what happens to the outgoing one, still running on tens of millions of phones that cannot all update at once. It publishes a legacy support window: the previous OS version enters a defined 24-month window during which it drops from feature updates to security patches only, and the vendor commits to that tier in writing. Within the window, users get everything they need to migrate safely — the OS keeps receiving critical vulnerability fixes, and the app store keeps accepting compatible builds so their existing apps keep working — but no new features arrive; the incentive to upgrade stays intact.
The coexistence is explicit: old and new versions are both supported at once, but at deliberately different levels. The support provided is scoped to what makes migration safe rather than comfortable — security, not novelty. And the sunset policy names the terminal date: after 24 months, security patches stop, the vendor's documentation says so plainly from day one, and enterprises managing fleets can plan device refreshes against a date they can trust. When the window closes, the old version is genuinely end-of-life — not a surprise, because the protocol declared its own expiry at the start.
How it works¶
- Publish the service tiers, not just a date. The window specifies what level of support the old path holds (full → fixes-only → security-only) so dependents know precisely what they can still rely on.
- Scope support to safe migration, not comfort. Support during the window is deliberately reduced to what keeps dependents secure and functional while they move, preserving the pull toward the replacement.
- Declare the end at the start. The closing date is announced when the window opens, so "temporary" is committed rather than perpetually renegotiated.
- Let the tier decay on schedule. The stepping-down of support is itself part of the protocol, a pre-announced ramp rather than an ad-hoc series of cuts.
Tuning parameters¶
- Window length — months versus years of continued support. Longer gives slow movers time and keeps trust; longer also delays freeing the resources tied up maintaining two paths.
- Service tier — full support versus security-only. A richer tier reduces migration pain but weakens the incentive to move and costs more to sustain.
- Decay schedule — how support steps down across the window. A steep ramp pressures migration; a flat one is gentler but prolongs the burden.
- Extension policy — whether the closing date can slip. Firm dates protect the bound; discretionary extensions protect stragglers but risk the window never truly closing.
When it helps, and when it misleads¶
Its strength is giving the rest of a transition a dependable footing: a deprecation's cutoff, a migration's schedule, and a customer's planning all rely on knowing exactly what the old path will still do and until when. A well-scoped window makes migration safe without making it optional. The pattern mirrors formal long-term support (LTS) commitments, which promise a fixed maintenance horizon[1] precisely so downstream users can plan.
Its failure mode is the window that never closes — each expiry met with "just one more extension" until the security-only tier becomes a permanent second system draining the resources the replacement needed. The classic misuse is offering full support during the window: comfort so complete that no one feels any reason to migrate, and the coexistence hardens into permanent dual maintenance. The guarding discipline is to commit the closing date publicly and treat extensions as rare and costly, to scope the tier to safety rather than comfort so the incentive to move survives, and to make the decay schedule visible so the window is obviously shrinking toward its end.
How it implements the components¶
coexistence_window— defines the bounded period in which old and new run together, at explicitly different and declared support levels.transition_support— supplies the scoped assistance (security fixes, compatibility maintenance) that keeps dependents safe and functional while they migrate.sunset_policy— names the terminal date and the stepping-down of tiers up front, so the window's end is committed rather than open-ended.
It does not enforce the switch-off itself or watch who is still on the old path (cutoff_rule, adoption_signal) — that is its nearest twin Deprecation Program; this window supplies the bounded support the deprecation's cutoff then acts upon.
Related¶
- Instantiates: Creative Destruction Management — supplies the bounded, declining-tier support protocol that gives dependents a safe runway.
- Sibling mechanisms: Deprecation Program · Product Sunset Plan · Data Migration Runbook · Technology Migration Plan · Infrastructure Replacement Program · Policy Phase-Out Schedule · Stakeholder Transition Workshop · Workforce Transition Support
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: The mechanism establishes a standing bounded service-level and closure-date commitment for the legacy path during migration.
Nearest alternative: Protocol, Workflow & Routine — Migration support follows procedures, but the operative form is the time-bounded support obligation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software lifecycle practice developed bounded, declining support tiers and announced end-of-life dates for predecessor systems.
Related originating lineages:
- Innovation & Entrepreneurship — Product transition strategy contributed managing creative destruction without stranding users.
- Law & Governance — Service and consumer-protection obligations contributed formal notice and residual-duty constraints.
- Organizational & Management Science — Transition management materially shaped migration support and stakeholder commitments.
Review resolution: Both independent reviews place the primary lineage in computer_science. The queued differences (alternate_origin_disagreement, encyclopedia_synthesis_disagreement) concern secondary metadata rather than primary provenance. The final retains law_governance, organizational_management, innovation_entrepreneurship only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=multi_domain records application breadth separately. encyclopedia_synthesis=true reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.
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] Canonical Ltd. Ubuntu Release Cycle. Canonical (n.d.). Documents formal LTS commitments with fixed, published maintenance horizons. registry ↩