Feature Sunset and Deprecation Plan
Every sunset guide says to notify affected users. This template counts the accounts whose way of using the feature has no replacement at all.
Free download · No account needed
Every deprecation guide gives the same two instructions: notify the users who are affected, and give your high-value accounts a personal call. Both are right and both point at the wrong column. Value is not usage, and the accounts that churn over a sunset are the ones whose particular way of using the feature has no equivalent in whatever replaces it. Nobody counts those before the announcement goes out, which is why the first anyone hears of them is a support ticket in the last fortnight.
So this pack does two joins before anybody is told anything. Every distinct way the feature is reached goes against what the replacement actually covers, which produces a list of accounts with nowhere to go. Then the usage data goes against the announcement list, which finds the accounts where the notice arrives at somebody who has never opened the thing. At the fictional Wexmoor those came to 43 accounts and 31 accounts, and 26 of the 84 heaviest users were in the first group.
Depth then sets the channel, measured as active weeks in a quarter rather than event volume. A call goes to the accounts running something through this every week, and a changelog line covers the 1,217 that stopped over a year ago. Send the usage export, every surface the feature is reachable from, and the announcement list. What comes back first is the count of heavy accounts with no path, then the launch brief and release notes the replacement needs.
What is in the pack
Affected Account Register
One row per account with the feature enabled. Active weeks in the trailing quarter, distinct users, days since last use, every pattern it uses, whether the replacement covers each one, its notice tier, and whether anybody on its announcement list has ever opened the thing.
Migration Tracking
Progress measured against accounts that have a path, not accounts notified, with both figures side by side so nobody quotes the flattering one by accident. Weekly rate from the last three weeks, and the date it puts the cutover on.
Escalation Log
Every contact with a category and a flag for whether the register predicted it. An escalation you predicted is a cost you chose. One you did not is a usage pattern nobody counted, and it goes straight back into the register.
Sunset Plan and Notice Sequence
The document that gets approved and the sequence derived from the register: channel and lead time per band, pause conditions, and the machine-readable signal for integrations. Where a contract or published policy sets a floor it wins, and Microsoft's Modern Lifecycle Policy commits to twelve months' notice where nothing succeeds the product. A defect is the other kind of unwanted news, and it goes to whoever it actually reached rather than following a planned sequence.
Migration Guide and Support Brief
The guide is organised by usage pattern rather than by product area, so a reader finds their own section in two lines. The brief tells the support team to open the register before answering, because depth and coverage change the entire reply.
How Usage Depth Is Computed, plus a weekly sweep
The method in eight steps, and an automation that recomputes both migration percentages, flags load-bearing accounts with no signed exemption, and names the accounts that acknowledged and then quietly stopped. Whether the replacement then gets used is a separate measurement.
How it works
- 1
Send the usage export
Per account and per user, with dates, covering at least a quarter and ideally eighteen months. Plus every surface the feature is reachable from, what replaces it, and the announcement list.
- 2
Depth by week, not by volume
River counts distinct active weeks rather than events, so an account with four hundred hits in one onboarding week ranks below one that opens it every Monday, and dormant accounts get checked against the same period a year earlier.
- 3
The replacement gets costed
Every distinct way the feature is reached gets one of three verdicts: covered, covered with work landing on the customer, or no equivalent. The union of accounts on an uncovered pattern is the number that decides whether the date is real.
- 4
Then it runs weekly
Migration recomputes against accounts that can actually move, the cutover date is re-forecast from the recent rate, and any account that acknowledged and then stopped surfaces with its owner named beside it.
Frequently asked questions
Every deprecation guide says to notify affected users. What is different here?
They all stop at deciding who to tell. None of them checks whether the replacement covers the way each account uses the feature. That is one lookup per usage pattern, available before any notice goes out. At Wexmoor it found 43 accounts with nowhere to go, 26 of them among the 84 heaviest users.
How do you define how heavily an account uses something?
Distinct weeks with at least one use in the trailing quarter, not total events. An account with four hundred events during one onboarding week is not a user and an account with one event every Monday is. Volume-ranked lists get that exactly backwards, which is why the top of them is usually wrong.
Is an account with no recent usage safe to remove quietly?
Check it against the same period a year earlier first. A trailing quarter is exactly the window that hides a quarterly close or an annual audit report. At Wexmoor 268 of 1,485 dormant accounts had used the feature in the same calendar month twelve months before, so 18% of that list was on a cycle rather than gone.
Why not just call the biggest accounts personally?
Because value is not usage. Wexmoor's top ARR decile held 231 accounts, of which 168 had not opened the feature in a quarter and only 28 were load-bearing. Calling that list means 168 unnecessary conversations and 56 accounts that use it every single week never hearing from a human.
How do you notify a scheduled job or an integration?
Not by email. Put the signal on the surface itself: a Deprecation field saying the endpoint is going, and a Sunset field carrying the date it stops responding. At Wexmoor 22 active accounts had every event attributed to a service account or a leaver, so no human existed to email.
What do we do about an account the replacement cannot serve?
Hold it out of the notice sequence and give it one of three outcomes, each with a date attached. The missing capability ships by a stated day, the account gets a written exemption to a stated day, or you tell them plainly there is no replacement and help them export. Never a dated notice they cannot meet.
How do we know the sunset is actually on track?
Measure migration against accounts that have a path, never against accounts notified. Wexmoor six weeks in read 96 of 205, or 46.8%, forecasting a thirteen-day slip. Against the 167 that could move it was 57.5% and four days of slack, with 38 accounts still walking into a cutover with nowhere to go.
Find out which accounts have nowhere to go
Send the usage export, every surface the feature is reachable from, and the announcement list. The first thing back is the count of heavy accounts the replacement cannot serve.
Stage my sunset notices