Sunset

Shipping has plenty of names. There's a release for pushing something out once, progressive delivery for opening it to 1 percent first and widening from there, and go-to-market (GTM) for the plan covering who hears about it, when, and through which channel. The opposite direction went unnamed for a long time. Turning a feature off showed up in meeting notes as one line — "we pulled that one" — and nowhere was it written down who does that, when, or how.

Without a procedure, things broke in two directions. One is turning things off too fast. At Pagedeck, Theo once shut down an old PDF export feature to cut server costs. Forty monthly users, so he read the impact as nothing. The next morning Sofia got a phone call. Two enterprise accounts sat inside that forty, and one of them built its Monday executive report with that feature every week. A small number and nobody are not the same statement. The forty who remain are usually the people who leaned on it hardest, which makes them the ones most stranded when it disappears.

The other direction is never turning anything off. The cost of leaving a feature in place is hard to see. One more line in a menu, one more branch in the code, one more item to check before every deploy. Taken one at a time none of them is a problem, so nobody is the first to propose removing it. Three years later the settings screen holds twenty-two entries and a new engineer has to ask which of them are still alive. At Pagedeck one old notification setting nobody switched on meant every change to notification code had to be made twice, and nobody had ever added up what that cost. The cost surfaces somewhere else entirely. Work that should take three weeks takes four because someone has to confirm the new path doesn't collide with the old one, a new user gets lost in the settings screen and files a question, and whoever picks up that question has to ask engineering whether the entry is still supported.

Sunset is the word that binds those two failures into one procedure. It treats retiring something with the same weight as shipping it. There's an end date, there are notices before it, there's something to use instead, and there's time in between for people to move. The assumption inside the word is that an unannounced shutdown is an incident in the same way an unannounced launch is. It's also the point where the decline stage in the product lifecycle — the one after introduction, growth and maturity — stops being something that happens on its own and becomes something people schedule and carry out.

Three terms sit underneath, split by character. Two are points on a timeline; one is what you hand the people crossing between those points. The first two have a fixed order, and the second can't come before the first.

The stages are the two markers planted on the road to shutdown.

1. Deprecation — the state of publicly announcing that something is going away and discouraging new use of it. The feature still runs. What changes is the signage. The help page gets a line at the top saying it is no longer recommended, the settings screen shows a banner, and if it's an interface other programs call, every call comes back carrying a warning. The point of this stage is to bring the number down. If people are still switching it on today, the shutdown date never arrives. That's why posting the notice and closing the paths that turn it on move as a pair — existing users keep what they have, while new users stop seeing it in the list at all.
2. End of life (EOL) — the point where support is formally declared over. Two things stop at once here. Breakage doesn't get fixed, and a support ticket doesn't get it restored. This date can match the day the feature physically disappears, or sit before it. When repair times are written into an enterprise contract, setting this point earlier than the contract's end means breaking a promise. The service level promised to a customer by contract is called an SLA, and the end-of-life date gets set only after reading that document. Naming this point matters because it lines up the inside and the outside. With no date on record, customers keep filing bug reports and whoever receives them decides case by case how far to go. Answers vary by person, and one repair granted quietly puts the feature back into a supported state.

A third date follows the two markers. It's the day the code and the data actually get deleted. It carries no name of its own, but it gets its own date, because leaving things running for a few weeks after support ends is safer. Customers who didn't finish moving can still pull their data out, and there's room to roll back if something turns out to be wrong. Teams often write this date into the notice as well, so that anyone reading it knows how long the data stays reachable after the feature stops being supported.

Support is the bridge for the people crossing. A migration guide is the document that says what to switch to and in what order to move. Without a replacement there's nothing to write, and with nothing to write there's no sunset to start. This is also where the order gets reversed most often in practice. Send the shutdown notice first and ship the replacement two months later, and for those two months there's no answer to give anyone who writes in. A good guide reads as a procedure rather than an explanation. How to check the current state, which buttons to press in which order, and what to look at afterward to confirm it worked, all at the level of specific screens. If something is lost in the move, that goes in too. Writing down in advance that old comment timestamps keep only minute-level precision in the new format beats letting customers discover it through a ticket.

Laid out on a timeline, the three become one schedule. Pagedeck's default spacing runs like this. The notice and deprecation start the same day, the end-of-life date sits 60 days later, and the code comes out 30 days after that. For anything enterprise accounts depend on, those become 90 and 60. Longer gaps don't mean people should move slowly — they exist so that anyone who gets stuck has time to ask and get an answer. Check-in points go on the same schedule: count the remaining users right after the notice, in the middle, and two weeks before shutdown, and if the number isn't falling as expected, find out why right then.

Who joins and when is fixed too. It starts with Mia weighing usage against maintenance cost and deciding whether to sunset at all. Once that's decided, Theo pulls the list of remaining users and builds the replacement path. A week before the notice goes out, Sofia contacts enterprise accounts separately, because receiving the same wording in a mass email and hearing it first from your own account contact are different events. On the day of the notice, Ravi updates the release note and the help pages together. If a contract is attached, Grace signs off on the date last.

"Let's sunset this. Forty monthly users and it eats time every sprint."

The cost of keeping it has passed the number of people using it, so the proposal is to end it.

"The deprecation notice went out but new usage keeps appearing. We need to pull this out of the signup screen first."

Announcing something doesn't stop the inflow, so the paths that switch it on have to close. A notice nobody read is the same as no notice.

"Put end of life after the contract expires. Cutting it before that means we're the ones breaking a promise."

Contract terms set the date before the engineering schedule does. Engineering can't pick the date alone when a contract is attached.

Last quarter Pagedeck retired its old comment feature. The newer one had shipped two years earlier and both had been running side by side ever since; documents still on the old one made up 3 percent of the total. Mia set a 90-day schedule, and the list Theo pulled held 210 accounts. Eleven of them were enterprise, so Sofia called each one.

Sixty days in, 130 accounts were still on it. There was a migration guide, three notice emails had gone out, and nothing had moved. When Theo looked into it, the button that converted old comments to the new format only appeared to people with edit rights on the document, and most of the contacts on those 130 accounts had read-only access. Moving the button dropped the remaining accounts to twenty-two in two weeks. The last holdouts got individual outreach with Grace's approval, and the date held. What the team actually got right here was the mid-point check rather than the shutdown. Without counting at day 60, the permissions problem would have surfaced the night before, and by then the only move left is pushing the date.

The most common mistake is reading a sunset as something that only happens to failed features. Removing something sounds like admitting it didn't work, so that's how it gets heard. Features people liked get retired too. Something better at the same job ships and there's no reason to keep both; a capability scattered across three products gets consolidated into one; an outside service the feature stands on closes down. Leave the mistake in place and sunset discussions turn into blame. The conversation opens with who built it, the person who built it ends up defending it, and after that nobody nominates their own feature. Dead features pile up in that kind of organization, and the settings screen keeps growing while the team spends more of each release checking paths nobody uses. Separating the decision from the builder's record is what makes candidates appear, and the teams that manage it tend to review a short list of retirement candidates on a fixed cadence rather than waiting for someone to raise one.

The second is believing a long window is enough to be safe. Give people 90 days and it looks like they'll spread the move across 90 days, but people move when a deadline is close. Pagedeck's old comment feature still had more than half its accounts left at day 60. The value of the window isn't the time it gives people to move — it's the time it gives someone who gets stuck to ask and get an answer. That makes counting what's left mid-way more important than the length of the window. Skip the count and you find out the night before that 130 accounts remain, and at that point the only option is to push the date. A date pushed once reads as a date that can be pushed again, so the next sunset's notice carries less weight. From the customer's side that's a reasonable read: it slipped last time, so not moving costs less than moving. Notices only move people in organizations that keep their dates, which is why the date is worth defending even when holding it costs more than slipping it once.