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

<!-- Guidance: How to use this template
- Fill sections 1 and 2 first (decision and impact). If you cannot say how many customers are affected and how heavily, you are not ready to set dates.
- Set the milestone dates in section 3 once, then derive every message in section 6 from that table. A date changed in one place must change everywhere in the same edit.
- Check customer contracts and service descriptions before announcing: a feature named in a contract, an order form or a service level commitment may need a different process.
- The worked example is fictional: Quillmoor Scheduling retires its Legacy PDF Report Builder in favour of Report Studio.
-->

## 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

<!-- Guidance: State the decision, the reasons and the alternatives you rejected. Customers will ask why; support needs a short honest answer. Record the decision in the decision log. -->

| 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

<!-- Guidance: Use real usage data for a recent window. Split customers by how much they depend on the feature, because each group needs a different level of help. Pitfall: counting accounts but not checking which ones have the feature in a contract. -->

| 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

<!-- Guidance: Give customers enough time for the effort the migration takes. The example uses about three months to read-only and six months to retirement; set your own periods from contract terms, any published deprecation policy and the migration effort. -->

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

```mermaid
stateDiagram-v2
  [*] --> Active
  Active --> Announced: M1 announcement
  Announced --> NoNewAdoption: M2 stop new adoption
  NoNewAdoption --> ReadOnly: M3 read-only
  ReadOnly --> Retired: M4 retirement
  Retired --> DataDeleted: M5 data deletion
  DataDeleted --> [*]
```

## 4. Replacement and migration path

<!-- Guidance: Map every capability of the old feature to the replacement, including the gaps. A gap you do not admit will surface as an escalation. Link the customer migration guide. -->

| 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

<!-- Guidance: Customers must be able to get their data out in a usable format before it is gone. Decide formats, how long export stays available and when deletion happens, and check these against contracts and privacy obligations. Questions below are prompts, not legal conclusions. -->

| 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

<!-- Guidance: Each message states the date, what changes, what the customer should do and where to get help. Lead with the action, not the reasons. Keep internal teams one step ahead of customers. -->

| 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

<!-- Guidance: Track migration progress against each milestone and decide in advance who can grant an extension and on what grounds. Plan how to pause the sunset if a serious gap appears. -->

| 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

<!-- Guidance: Close the plan only when code, data, documentation and messaging are all clean. -->

- [ ] 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](../docs/deprecation-notice.md) for the public announcement, [migration guide](../docs/migration-guide.md)
- [API versioning and deprecation policy](../architecture/api-deprecation-policy.md) when an API is involved
- [Release notes](../dev/release-notes.md), [communication plan](../project/communication-plan.md)
- [Renewal and churn risk plan](../customer-success/renewal-churn-risk-plan.md) for heavy users at risk
- [Terms of service](../legal-lite/terms-of-service.md), [SLA outline](../legal-lite/sla-outline.md), [refund and cancellation policy](../legal-lite/refund-cancellation-policy.md)
- [Data subject request procedure](../compliance/data-subject-request-procedure.md)
- [Decision log](../business/decision-log.md), [roadmap](./roadmap.md), 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.