How to Assess Whether to Sunset a Product: Steps, Examples and Checklist

When you need this document

Write a sunset assessment when a product, feature or capability is consuming more than it returns — declining usage, mounting maintenance cost, strategic misalignment — or when a replacement makes overlap untenable. It belongs in the Scale or Sunset phase, before any customer communication and well before an end-of-life date is floated internally. If the real question is whether to invest further rather than retire, that is a portfolio or scale decision, and forcing it through a sunset lens will bias the answer.

Gather these first

• Usage, revenue and retention data for the product over a meaningful period, segmented by customer type
• The true cost of keeping it alive: engineering maintenance, support load, infrastructure, opportunity cost
• A list of who still depends on it — customers, internal teams, integrations, contracts
• The alternatives customers would move to, yours or a competitor's
• Contractual, regulatory or data-retention obligations that constrain timing
• Input from support, operations and commercial teams who will carry the transition

Step by step

1. Establish the trigger with numbers, not weariness

   Name what put the sunset question on the table and evidence it: usage trend over a meaningful window, revenue against fully-loaded cost, incidents and support burden, or the strategic work it blocks. Teams often want to retire things they are tired of maintaining, and tiredness is not a case. Conversely, quiet products sometimes anchor your stickiest accounts — which is precisely what the data step exists to reveal.

   What good looks like: The trigger is stated as measurable decline or cost, over a defined period, from named data sources.

2. Map exactly who still depends on it

   Identify every dependency before forming a view: which customers still use it and how intensively, which segments they represent commercially, which internal systems or teams rely on it, and which contracts reference it. Segment the users — a hundred dabblers and three flagship accounts are different problems. This map is the foundation for every later judgement about risk, migration and communications.

   What good looks like: You can state how many users would be affected, who the highest-value ones are, and what each group would lose.

3. Give the alternatives to retirement a fair hearing

   Retirement is one option among several: reposition for a niche that still values it, migrate users to a successor, reduce to maintenance-only investment, or sell or transfer it. Assess each against the same criteria — cost, customer impact, strategic fit — rather than lining them up as straw men. An assessment that only ever considered killing the product will be re-litigated by every stakeholder who spots the gap.

   What good looks like: At least one non-retirement option is assessed seriously enough that a reviewer could choose it from your analysis.

4. Design the migration path before recommending the ending

   For the retirement scenario, work out where each user segment goes: to your successor product, to an export, to a partner, or — honestly — to a competitor. Define what data they can take, what the equivalent capability is, and where the experience will be worse. If a viable migration path does not exist yet, the recommendation may need to be 'build the path first, then sunset' — a very different plan with a very different timeline.

   What good looks like: Every affected segment has a named destination, and the gaps where no good destination exists are admitted.

5. Confront the risks of leaving as well as staying

   Set out both risk ledgers. Retiring carries churn beyond the product itself, brand damage, contractual exposure and internal knowledge loss. Keeping it carries mounting maintenance cost, security and compliance decay, and the ongoing tax on team focus. Rank both lists by severity, attach mitigations where they exist, and be explicit about which risks are simply being accepted.

   What good looks like: Both scenarios — retire and retain — have honest risk lists, so the recommendation reads as a weighed choice rather than an escape.

6. Plan the communications and support runway

   Sketch how affected customers hear the news: from whom, in what order, how far ahead of the end date, and what support they get through the transition. Loyal customers judge you by how you end things — a rushed or impersonal wind-down does more damage than the retirement itself. Confirm that support, operations and account teams have seen the plan and can staff it, because they inherit the hardest conversations.

   What good looks like: The plan names notice periods, communication owners and support commitments that the teams carrying them have agreed to.

7. Recommend, and define what 'closed' means

   Finish with one recommendation and, if it is retirement, the closure criteria: the conditions that mark the sunset complete — users migrated or notified, data handled per obligations, systems decommissioned, contracts resolved. Name the accountable owner and the decision you need from leadership. Without closure criteria, sunsets drift into zombie states where the product is dead but never quite buried, accruing cost with no benefit.

   What good looks like: A reviewer can see the recommendation, the decision required, the owner, and the specific conditions under which the sunset is finished.

Common mistakes

• The assessment is written to justify a decision already made, and stakeholders can tell — so they re-open it repeatedly. — Assess the alternatives with real numbers before writing the recommendation, and show that work. A decision that survives an honest comparison stays decided; one that skipped it gets re-litigated for months.
• Dependencies surface after the announcement — a flagship account, a contractual clause, an internal system nobody checked. — Do the dependency mapping as its own step with commercial, legal and engineering input before any recommendation. Every dependency discovered after customer communication costs multiples of the effort of finding it now.
• The recommendation says 'retire' but nobody defined done — the product lingers half-alive for years, still consuming maintenance. — Write closure criteria into the assessment itself: migration complete, data obligations met, systems switched off, contracts closed. Assign an owner for reaching them, not just for making the decision.
• Customer impact is averaged — '4% of active users' — hiding that those users include three of your largest accounts. — Segment the affected base by commercial value and intensity of use, and assess impact per segment. Averages are how sunset assessments hide their most expensive risk.
• The communications plan is an afterthought, drafted after approval and days before customers are told. — Treat communications and support runway as part of the assessment, agreed with the teams who will deliver it. How you retire a product is remembered longer than the product itself.

Before you call it done

• The trigger is evidenced with usage, cost or strategic data over a defined period
• Affected users are mapped and segmented by commercial value, with internal and contractual dependencies included
• Retirement is weighed against reposition, migrate and reduce-investment options on equal terms
• Every affected segment has a named migration destination, with gaps admitted
• Risks of retiring and of retaining are both listed, with mitigations or accepted-risk notes
• Notice periods, communication owners and support commitments are agreed with the teams delivering them
• The recommendation includes closure criteria, an accountable owner and the decision required

Frequently asked questions