When the stage becomes relevant
Retire can become relevant when:
- the underlying user or business need no longer exists;
- another product, service, or process can meet the continuing need more responsibly;
- products should be consolidated to reduce duplication or fragmented experience;
- use or benefit no longer justifies cost and risk;
- technology, data, architecture, vendors, skills, or operations cannot be sustained responsibly;
- security, privacy, legal, compliance, accessibility, or contractual conditions make continued use unacceptable;
- strategy, policy, regulation, funding, or organizational ownership changes;
- a legacy product must close after a replacement reaches sufficient readiness and adoption;
- a product has effectively been abandoned but remains accessible or operational;
- evolution options do not provide credible continuing value.
Retirement planning should begin before ownership, funding, expertise, or vendor access disappears.
Questions and decisionsRead section
Continuing need and replacement
- Does the need still exist, and for which people or organizations?
- Will a replacement, consolidated product, manual process, third party, or no service address it?
- Does the replacement meet proven needs and accessibility requirements?
- Which users cannot transition through the standard path?
- What temporary coexistence is necessary?
Users and communication
- Who currently uses, depends upon, supports, administers, or receives output from the product?
- How and when will each group learn what is changing, why, and what action is required?
- Which in-progress work, saved preferences, links, bookmarks, integrations, or assistance paths will be affected?
- What support will users need before, during, and after withdrawal?
- How will the organization prevent users from reaching an unsupported dead end?
Data, records, and access
- Which data and records must migrate, archive, retain, delete, return, or remain accessible?
- Which privacy, consent, legal hold, audit, regulatory, contractual, and retention conditions apply?
- Who can access historical information after retirement?
- How will the organization confirm data completeness, integrity, provenance, and deletion?
- Which reports, models, analytics, and downstream decisions depend on the product data?
Technology and operations
- Which applications, infrastructure, domains, certificates, integrations, interfaces, identities, licenses, devices, vendors, and support processes must change or close?
- Which other products or workflows depend on them?
- How will traffic, messages, transactions, and in-progress work be redirected or completed?
- What rollback or contingency options are needed during transition?
- Which monitoring and support should remain after user access ends?
Governance and completion
- Who owns the overall retirement decision and each transition obligation?
- Which financial, procurement, vendor, workforce, security, privacy, legal, compliance, accessibility, and communication decisions remain?
- What evidence authorizes each withdrawal step?
- What conditions would delay, pause, or reverse part of the transition?
- What proves that retirement is complete and no product obligation remains without an accountable owner?
Activities and evidenceRead section
Useful retirement work may include:
- confirming the decision rationale, scope, authority, timing, and affected products or capabilities;
- researching continuing user needs and the transition needs of different groups;
- inventorying users, processes, data, records, integrations, infrastructure, vendors, contracts, support, content, and organizational dependencies;
- evaluating replacement readiness, accessibility, capacity, support, and adoption;
- defining coexistence, migration, archival, retention, deletion, redirect, and shutdown sequences;
- designing communications, notices, in-product messages, support paths, and assisted transitions;
- migrating users, preferences, records, histories, integrations, and in-progress work where appropriate;
- validating data integrity, access, deletion, replacement behavior, redirects, and transition outcomes;
- updating policies, documentation, training, ownership, financial records, inventories, and portfolio records;
- terminating or changing vendors, licenses, infrastructure, credentials, domains, interfaces, and monitoring;
- managing incidents, exceptions, users who do not transition, and temporary workarounds;
- preserving evidence, decisions, lessons, and knowledge that another product or future organization may need;
- monitoring after withdrawal to detect broken journeys, unmanaged dependencies, unauthorized access, or continuing demand;
- recording closure evidence and accountable acceptance of remaining obligations.
Retirement should be phased when that approach protects users, validates the transition, or reduces irreversible risk. A fixed date should not erase evidence that a critical dependency remains.
Typical outputsRead section
Useful Retire-stage outputs may include:
- a retirement decision, rationale, scope, and authority;
- an inventory of affected users, data, technology, operations, vendors, contracts, content, and dependencies;
- a continuing-need and replacement assessment;
- user, employee, partner, and stakeholder transition plans;
- communication, support, accessibility, redirect, and exception plans;
- migration, coexistence, archival, retention, deletion, and access decisions;
- technical decommissioning and integration-removal plans;
- financial, procurement, security, privacy, legal, compliance, risk, and audit records;
- transition measures, thresholds, contingencies, and rollback conditions;
- validation evidence for replacement, migration, redirects, data treatment, and closure;
- product, portfolio, configuration, documentation, and ownership updates;
- final closure evidence and ownership of any residual obligation.
Closure should be based on evidence rather than the scheduled shutdown date.
Contributing responsibilitiesRead section
Product and portfolio leadership
Product management connects the retirement rationale to users, outcomes, value, transition, evidence, and accountability. Product ownership coordinates delivery-facing retirement work and backlog decisions. Portfolio governance addresses consolidation, replacement, investment, and ownership across products.
Users, research, experience, content, and accessibility
Users and affected stakeholders provide evidence about continuing needs and transition barriers. Research, service-design, experience, content, and accessibility specialists design understandable, inclusive transitions and prevent abandoned journeys.
Engineering, architecture, data, operations, and support
Technical specialists inventory and change applications, integrations, infrastructure, access, monitoring, and dependencies. Data specialists manage migration, retention, deletion, lineage, access, and downstream use. Operations and support specialists manage coexistence, continuity, incidents, communications, assistance, and closure.
Security, privacy, legal, compliance, finance, and procurement
Specialists address access removal, information protection, consent, retention, deletion, legal hold, audit, regulation, contracts, vendors, licenses, cost, and risk.
Business and organizational leaders own policy, process, workforce, stakeholder, and operating-model changes. A retirement leader should coordinate the complete decision without absorbing specialist accountability.
Cross-lifecycle considerationsRead section
- Opportunity and Discover may reassess whether a continuing need creates a new product opportunity.
- Define and Design establish the replacement or transition experience.
- Develop and Validate implement and evaluate migration, redirects, access, data treatment, and decommissioning changes.
- Launch and Adopt introduce a replacement and help users transition.
- Operate sustains coexistence and monitors withdrawal until obligations are complete.
- Evolve provides the evidence that retirement is more responsible than further change.
Retirement can move backward when evidence shows that a replacement does not meet the continuing need or a dependency remains unresolved. Delaying one part does not require abandoning the entire retirement direction.
Common mistakesRead section
Treating retirement as a technical shutdown
Turning off infrastructure can abandon users, data, records, contracts, integrations, and legal or operational obligations.
Assuming the replacement solves the need
Validate the replacement for affected users and contexts. Feature similarity does not establish accessibility, capacity, support, or outcome continuity.
Waiting until funding or expertise disappears
Late retirement increases risk because the people, vendors, records, and access needed for a responsible transition may no longer be available.
Communicating only near the shutdown date
Different users need time, repeated notice, clear actions, alternatives, and support. Communication should match consequence and transition complexity.
Ignoring hidden dependencies
Reports, bookmarks, automated jobs, downstream systems, historical records, and informal workflows may outlive visible product use. Inventory and monitor them.
Deleting or retaining data by default
Both choices can create harm and obligation. Make explicit, authorized decisions about migration, retention, access, archival, and deletion.
Declaring completion when access closes
Residual infrastructure, credentials, contracts, records, redirects, support, and monitoring may continue. Confirm closure through evidence.
Treating retirement as failure
Responsible retirement can protect users, reduce risk, remove duplication, and redirect investment. The decision should reflect current evidence rather than product history or sentiment.
Decision signals
Begin retirement
Begin when continued operation is no longer justified, a responsible authority owns the decision, continuing needs and dependencies are sufficiently understood, and the organization can plan a safe transition.
Phase or limit withdrawal
Phase retirement when user groups, regions, capabilities, data, integrations, or replacement readiness differ. Each phase should have evidence, owners, communication, support, and contingency.
Pause or revisit
Pause a withdrawal step when a critical need, replacement gap, data obligation, dependency, accessibility barrier, or unacceptable transition risk emerges. Revisit Discover, Define, Design, Develop, Validate, Launch, or Adopt for the decision that requires attention.
Reverse a transition step
Reverse a reversible step when the replacement or migration creates material harm and continued temporary operation is safer. Record the revised plan and conditions.
Confirm completion
Complete retirement when affected users have an appropriate outcome, required data and records are handled, dependencies and access are closed or transferred, obligations and contracts are addressed, redirects and support are in place for their defined period, residual risk has an owner, and closure evidence is accepted.
Applied-example continuation
Years later, a unified customer platform replaces the separate status experience and supports the same need across a broader relationship. Operating and portfolio evidence shows that maintaining both products would duplicate data, support, security, and experience responsibilities.
Retirement planning confirms that customers still need request status, historical records, accessible account access, notification preferences, and support. The organization validates those needs in the replacement before moving users. It inventories request types, accounts, preferences, status histories, links, integrations, notifications, support materials, vendor services, retention rules, and reporting dependencies.
The transition migrates preferences with appropriate notice and consent handling, preserves required historical records, redirects account links, updates notifications and support guidance, and runs both products temporarily for selected request types. Monitoring identifies customers who continue reaching old links and one downstream report that still depends on the legacy status feed.
The organization resolves the report dependency, confirms migration and access, removes credentials and integrations, terminates the related vendor service, maintains redirects for the approved period, and records data-retention and deletion decisions. Retirement completes only after the unified platform meets the continuing need and closure evidence confirms that no unmanaged product responsibility remains.
Source notesRead section
- GOV.UK Service Manual — Retiring your service. Supports considering continuing user needs, coordinating with replacement services, communicating with users, redirecting journeys, and protecting information.
- GOV.UK Service Manual — How the live phase works. Supports retirement when needs or cost no longer justify continued operation.
- NIST Special Publication 800-160 Volume 1. Supports disposal, transition, information protection, stakeholder needs, risk, and lifecycle evidence.