Feature Sunset Plan Template

Customer-facing feature retirement plan: decision, impact by segment, dated milestones, replacement mapping, data export and deletion, comms sequence, exceptions

Product & ProjectStandardfeature sunset planUpdated Oct 29, 2026

Open in editorDownload .md

How to use: 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.

Preview

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	Email	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.

Related templates

Product & Project