Feature Sunset Plan Template
Customer-facing feature retirement plan: decision, impact by segment, dated milestones, replacement mapping, data export and deletion, comms sequence, exceptions
Cómo usar: Use it when you retire a feature customers use, before anything is announced. Fill the decision and the impact assessment first, then set the milestone dates once and derive every message from them. The main pitfall is missing a contract or order form that names the feature, or deleting data before customers could export it.
Vista previa
Feature Sunset Plan: [Feature name]
An internal plan for retiring a customer-facing feature: why it is being retired, who is affected, the dated milestones from announcement to data deletion, the replacement and migration path, how customers get their data out, the communication sequence, and how exceptions and rollback are handled. The public announcement itself is written with the deprecation notice template (
docs/deprecation-notice); API versions follow the API versioning and deprecation policy (architecture/api-deprecation-policy). Based on common product-management practice; the data and contract section names EU, UK and US rules as dated examples with official links. Replace every[bracketed]value and every row marked Example. This is a planning format, not legal advice: check the current official texts, your customer contracts and a qualified professional.
Document control
| Field | Value |
|---|---|
| Document ID | [SUNSET-PRODUCT-NNN] |
| Version | [0.1] |
| Status | [Draft / Approved / Announced / Read-only / Retired / Closed] |
| Owner | [@product-manager] |
| Approvers | [Product lead, engineering lead, customer success lead, legal or privacy contact] |
| Feature being retired | [Name, where it appears in the product] |
| Replacement | [Feature name, or "none"] |
| Announcement date | YYYY-MM-DD |
| Retirement date | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |
| Classification | [Internal until announced] |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Product lead | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Customer success lead | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Legal or privacy contact | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@owner] | First draft |
1. Decision and rationale
| Item | Value |
|---|---|
| Decision | Example: Retire the Legacy PDF Report Builder; Report Studio replaces it |
| Reasons | Example: Two report engines double the maintenance cost; the legacy engine cannot meet the accessibility requirements for tagged PDFs; Report Studio covers all legacy report types |
| Alternatives considered | Example: Keep both (rejected, cost), freeze legacy with no fixes (rejected, unpatched dependency) |
| Decision record | [Link to the decision log entry] |
2. Impact assessment
| Measure | Value | Source |
|---|---|---|
| Active accounts (last 90 days) (Example) | 18,000 | Product analytics |
| Accounts that used the feature in the window (Example) | 3,240 (18.0% of active) | Product analytics |
| Heavy users (weekly use, scheduled reports) (Example) | 410 (12.7% of affected accounts) | Product analytics |
| Accounts with the feature named in a contract or order form | [N] | Contract review |
| Integrations or API clients that depend on it | [N] | API logs |
| Segment | Definition | Treatment |
|---|---|---|
| S1 heavy (Example) | Weekly use or scheduled reports | Named contact from customer success, assisted migration |
| S2 light (Example) | Used in the window, less than weekly | Email sequence, in-app banner, self-serve guide |
| S3 contract (Example) | Feature named in a contract | Account team handles per contract terms, legal review |
| S4 none | No use in the window | Release note only |
3. Milestones
| Milestone | Date | Days after announcement | What changes for customers |
|---|---|---|---|
| M1 Announcement (Example) | 2027-02-01 | 0 | Notice published, banner shown, emails sent |
| M2 Stop new adoption (Example) | 2027-02-15 | 14 | Accounts that never used the feature can no longer turn it on |
| M3 Read-only (Example) | 2027-05-03 | 91 | Existing reports can be viewed and exported, not edited or scheduled |
| M4 Retirement (Example) | 2027-08-02 | 182 | Feature removed from the product |
| M5 Data deletion (Example) | 2027-11-01 | 273 | Remaining legacy report data deleted from production and, by [date], from backups |
4. Replacement and migration path
| Legacy capability | Replacement | Gap | Plan for the gap |
|---|---|---|---|
| Custom PDF layouts (Example) | Report Studio templates | None | n/a |
| Scheduled email delivery (Example) | Report Studio schedules | Hourly schedules not supported | Added before M3, tracked as PBI-388 |
| Legacy report links in customer intranets (Example) | New share links | Old links stop at M4 | Redirect old links to a notice page until M5 |
Migration support: [self-serve guide link], [automated converter, if any, with its known limits], [office hours or assisted migration for S1].
5. Data export and deletion
| Item | Decision |
|---|---|
| What data the feature holds | Example: report definitions, generated PDFs, schedules, recipient lists |
| Export formats | Example: PDFs as a ZIP archive, definitions and schedules as JSON and CSV |
| Export available from and until | Example: from M1 until M5 |
| Bulk export for administrators | [Yes / No, and how] |
| Deletion from production | [Date, method] |
| Deletion from backups | [Date or rotation period] |
| Personal data in the feature | [Yes / No, which categories] |
Questions for your legal or privacy contact:
- Do customer contracts, the terms of service or a service description promise this feature, a notice period or a data return period?
- Does any personal data in the feature fall under a data portability or deletion obligation, and is the export format structured, commonly used and machine-readable?
- Does a cloud or data processing contract have switching or exit terms that apply to this change?
- Do refunds or credits apply to customers who paid for the feature specifically?
Dated examples of rules to check (check the current official text):
- EU: General Data Protection Regulation, Regulation (EU) 2016/679, Article 20 (right to data portability) and Article 17 (right to erasure): https://eur-lex.europa.eu/eli/reg/2016/679/oj. The EU Data Act, Regulation (EU) 2023/2854, applicable since 12 September 2025, contains rules on switching between data processing services; check whether your service falls in scope: https://digital-strategy.ec.europa.eu/en/policies/data-act
- UK: UK GDPR Article 20 and the ICO guidance on the right to data portability (respond within one month, extendable in some cases): https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-data-portability/
- US: Federal Trade Commission Act, 15 U.S.C. 41 to 58, which prohibits unfair or deceptive acts or practices; announcements and marketing must not misstate what customers keep: https://www.ftc.gov/legal-library/browse/statutes/federal-trade-commission-act
6. Communication plan
| When | Audience | Channel | Message | Owner |
|---|---|---|---|---|
| M1 minus 10 working days (Example) | Support, sales, customer success | Internal briefing, FAQ | Decision, dates, talking points, escalation path | [@pm] |
| M1 minus 5 working days (Example) | S1 and S3 accounts | Account team call | Personal notice before the public announcement | [@cs-lead] |
| M1 (Example) | All affected accounts | Email, in-app banner, deprecation notice page, release notes | Dates, replacement, migration guide, export link | [@pm] |
| M3 minus 14 days (Example) | Accounts still using it | Email, banner | Read-only on M3, migrate now | [@pm] |
| M4 minus 14 days (Example) | Accounts still using it | Email, banner | Removal on M4, export before M5 | [@pm] |
| M5 minus 14 days (Example) | Accounts with remaining data | Final export reminder, deletion date | [@pm] |
7. Monitoring, exceptions and rollback
| Indicator | Target before M3 (example) | Target before M4 (example) | Current |
|---|---|---|---|
| S1 accounts migrated | 80% (328 of 410) | 100% or exception granted | [Value] |
| Weekly users of the legacy feature | under 500 | 0 outside exceptions | [Value] |
| Support tickets tagged "sunset" per week | Falling week on week | Falling week on week | [Value] |
Exceptions:
- Who can approve: [Example: product lead with customer success lead]
- Maximum extension: [Example: 60 days, read-only only]
- Record: every exception logged with account, reason and end date
Pause or rollback: [Conditions under which milestones move, for example a replacement gap found that blocks S1 accounts, and who decides]. If dates move, update section 3 and reissue every message in section 6.
8. Closure
- Feature code, flags and configuration removed
- Data deleted as set out in section 5, with evidence kept
- Help centre articles, screenshots and API documentation updated or redirected
- Deprecation notice page updated to "retired" and kept at its URL
- Lessons learned recorded (what customers struggled with, what to change next time)
Related templates and references
- Deprecation notice for the public announcement, migration guide
- API versioning and deprecation policy when an API is involved
- Release notes, communication plan
- Renewal and churn risk plan for heavy users at risk
- Terms of service, SLA outline, refund and cancellation policy
- Data subject request procedure
- Decision log, roadmap, beta program plan (
product/beta-program-plan)
Standard and licence note
Based on common product-management practice for retiring customer-facing features; it follows no single published standard. The data and contract section names Regulation (EU) 2016/679, Regulation (EU) 2023/2854, the UK GDPR with ICO guidance and the US Federal Trade Commission Act as examples only, checked on 2026-10-30; laws and guidance change, so check the current official text and a qualified professional before relying on it. All wording is original. This is not legal advice. Template licence: MIT.
Plantillas relacionadas
A/B Test Plan Template
Pre-registered A/B test: hypothesis, randomisation unit, metrics, Lehr sample size, SRM and peeking rules, novelty, privacy and consent, decision rule, results
Producto y proyectoBeta Program Plan Template
Beta programme plan: learning questions, cohorts and size caps, entry criteria, feedback loop, consent and privacy questions, exit criteria, closure
Producto y proyectoRelease Plan Template (Agile Release Planning)
Agile release plan: release goal, MoSCoW scope, sprint mapping, velocity range forecast, milestones, dependencies, risks, communication