End-of-Life, Supportability, and Technology Obsolescence Across the SDLC

Defines lifecycle governance for supportability, maintenance horizons, supplier and component end-of-life, technology obsolescence, replacement readiness, and orderly Retirement from initial strategy through Operations.

Governing Principle

Treat supportability and obsolescence as predictable lifecycle conditions that must influence selection, Architecture, funding, Release planning, Operations, replacement, and Retirement before they become emergencies.

Required Lifecycle Treatment

Identify support periods, maintenance obligations, component and supplier dependencies, skill availability, licensing, patching, upgrade paths, compatibility, data portability, recovery capability, replacement lead time, and exit constraints. Distinguish Product end-of-sale, end-of-maintenance, end-of-support, internal support withdrawal, and actual enterprise Retirement. Establish ownership and trigger points for reassessment, upgrade, replacement, isolation, extended support, Risk acceptance, or Retirement.

Application Through the SDLC

During Intake and Research, evaluate expected lifespan, market direction, supplier stability, portability, and replacement options. During Planning and Requirements, define supportability, upgrade, documentation, skills, evidence, and exit requirements. During Design and Build, reduce avoidable lock-in, isolate volatile dependencies, automate maintenance, and preserve technical knowledge. During testing and staging, validate upgrade, rollback, recovery, migration, and support procedures. During Production and Operations, monitor support status, component age, vulnerabilities, supplier roadmaps, skills, capacity, and operational burden. During Retirement, close dependencies, migrate or dispose of data, terminate access and contracts, update inventories, and retain required evidence.

Governance and Evidence

Maintain authoritative support and obsolescence information for Products, Services, components, platforms, Models, interfaces, and suppliers. Link approaching dates and conditions to owners, funding, roadmap decisions, Risks, exceptions, Technical Debt, and replacement work. Do not allow expired support to become an undocumented normal operating condition.

Connections to Related IF4IT Practices and Inventories

Use Technology Portfolio Management (TPM) Best Practices and the Software Technologies Inventory and Attributes to select approved technologies, expose standards exceptions, record configuration baselines, and manage supportability and obsolescence. Use Application Portfolio Management (APM) Best Practices and the Applications Inventory and Attributes to validate rationalization posture, dependency impacts, replacement readiness, ownership, and authoritative lifecycle-state updates before retirement.

Apply Technical Debt Management Best Practices and the Technical Debt Inventory and Attributes to identify, qualify, record, prioritize, remediate, accept, and periodically reassess intentional, inherited, emergent, and deferred lifecycle obligations.

Apply Service Management Best Practices and Service Catalog Best Practices to define operational ownership, support models, service levels, monitoring, knowledge transfer, and customer-facing service commitments before and after Production.