What does it mean to "sunset" a product?

Sunsetting means shutting down a product, feature, or service in a planned way rather than letting it quietly break or disappear. It includes telling users in advance, giving them a way to get their data out, offering a path to something that still works, and setting a real shutdown date.

How do you decide when a product should be sunset?

Compare what it costs to keep running against what it earns or how much it gets used. If the ongoing cost of maintaining a product (engineering time, infrastructure, support load, security patching) is higher than its revenue and its active usage is low and falling, that is the signal to plan a sunset rather than keep funding it by default.

What counts as "maintenance cost" for this decision?

It is every ongoing cost tied to keeping the product alive: the engineering hours spent on bug fixes and dependency upgrades, the infrastructure bill, the support tickets it generates, and the security patching it needs. A useful gut check is asking how many hours a month the team spends on it and multiplying by what that time is worth doing instead.

Why not just look at usage numbers alone?

Usage alone can be misleading in both directions. A product with declining usage might still be cheap to maintain and worth keeping for the customers who depend on it, while a product with steady usage might cost so much to keep running that it is not worth the return. Cost and usage have to be read together, not separately.

What is the difference between a clean sunset and an abandonment?

A clean sunset gives users advance notice, a way to export their data, a migration path if one exists, and a firm date, all communicated before anything stops working. An abandonment is when a product just stops getting updates, breaks quietly over time, and users find out when something they relied on no longer works, with no path forward and often no way to get their data.

How much advance notice should a sunset give users?

There is no single correct number, but the notice should be long enough for a user to actually complete a data export and, if needed, move to something else, not just long enough to check a compliance box. For a product handling business-critical data, that usually means months rather than weeks, timed around your users' own schedules rather than only your own.

What should a data export plan include?

It should let every user get a complete, usable copy of what they put into the product, in a format they can actually open and use elsewhere, before the shutdown date. A good test is trying the export yourself as if you were a customer: if you cannot make sense of the file you get, your users will not either.

Should a sunset plan include a migration path for existing users?

Where one is possible, yes. Pointing users at a replacement product, whether your own or a competitor's, is more respectful than leaving them with an export file and no next step. Where no real replacement exists, be honest about that instead of implying one does.

Is it ever better to keep a low-usage product running instead of sunsetting it?

Sometimes. If the maintenance cost is genuinely low, a small number of dependent users can be worth keeping the product alive for, especially if it runs with little engineering attention. The decision rule only points toward sunsetting when the ongoing cost is out of proportion to what the product returns, not whenever usage is small.

Who should be accountable for a sunset going well?

The team that owns the product, not one individual. A sunset plan should be a written document with an export mechanism, a migration path, and a communicated date, reviewed by the team the same way a launch plan would be, because a badly run shutdown damages trust the same way a badly run launch does.

How to decide when to sunset a product: Reveneau

We have sat in the planning meeting where a product review turns into an argument about feelings instead of numbers. Someone says "people still use it." Someone else says "but nobody's touched it in months." Both statements can be true at once, and neither one, by itself, tells you whether to keep paying for it.

In the work we do, the products that get sunset well share one thing: the team separated two questions that usually get tangled together. What does this cost to keep alive? And what is it actually returning, in revenue or in real, active usage? Answer those separately, compare them, and the sunset decision stops being a debate about sentiment. What follows is that decision rule, and the operational plan that keeps a sunset from turning into an abandonment.

Start with the true cost of keeping it alive

Every running product has a maintenance bill, and most teams underestimate it because it is spread across a dozen small tasks instead of one line item.

Add up the engineering hours spent on it in a normal month: bug fixes, dependency upgrades, security patches, the on-call pages it generates. Add the infrastructure cost it carries on its own, not shared with anything else. Add the support tickets tied to it and the time it takes someone to answer them. None of this needs to be exact. A rough total, built honestly, is enough to compare against what the product returns.

The part teams miss most often is the cost of just staying current. A dependency with a known vulnerability does not wait for a convenient sprint. If a product still has active users, someone has to patch it anyway, whether or not anyone on the team wants to spend time on it. That obligation does not show up on a roadmap, but it shows up on every on-call schedule until the product is either invested in properly or shut down.

Weigh that cost against usage and revenue, not against sentiment

Once you know what a product costs, put it next to two numbers: how much revenue it generates, directly or as a dependency for something that does, and how many people actually use it, measured by real activity rather than by account count.

A product can fail this test in either direction. Low usage with low maintenance cost is often fine to leave alone. It is not hurting anyone and it is not costing much to keep running. The products worth sunsetting are the ones where the maintenance cost is out of proportion to the return: a feature that takes real engineering time every month, that generates support load, and that a small and shrinking group of people actually touch.

This is also where "sentiment" gets separated from the decision. A product can be well-loved by a handful of vocal users and still be the wrong thing to keep funding, if the cost of keeping it running is paid by every other project the team could be working on instead. That tradeoff is real whether or not anyone says it out loud in the meeting.

Revenue and usage do not always point the same direction, and when they disagree, read them together rather than picking whichever one makes the decision easier. A product with falling usage but a handful of large accounts still paying for it might be worth keeping, at least until those contracts run out. A product with steady usage but no direct or indirect revenue, and a support queue that keeps growing, might be the one to cut even though the usage chart looks healthy. Neither number wins by default. The question is always the same: does what this costs to run still make sense next to what it returns, this quarter, not the quarter it launched.

Once the number says sunset, plan it like a launch

This is the part most teams skip, and it is the part that determines whether users trust you the next time you ship something new.

A clean sunset has three pieces, decided before anyone outside the team hears about it:

A data export. Every user gets a real way to take what they put into the product with them, in a format they can actually open and use somewhere else. Test this yourself before you announce anything. If you cannot make sense of the file the export produces, your users will not be able to either, and you will spend the notice period fielding support tickets instead of giving people time to leave cleanly.

A migration path, if one exists. If there is a replacement, your own product or someone else's, point people at it directly instead of leaving them with an export file and a dead end. If there genuinely is no replacement, say that plainly rather than implying a path that does not exist.

For a business tool, a migration path usually means more than a link to a competitor. It means documenting the fields in your export well enough that a user can map them into whatever they move to next, and it means giving your support team a script to follow when someone asks "what do I do with this file." A migration path that only exists as a sentence in a shutdown email is a suggestion, and most users will not have the time to turn a suggestion into a working setup somewhere else before your service goes dark.

A real date, communicated early. Google's shutdown of Stadia is a useful example of the mechanics done in public: the company announced the shutdown on September 29, 2022, set the actual end date for January 18, 2023, and committed to refunding every hardware and software purchase. Users had a fixed window to plan around, a clear statement of what would happen to their money, and no ambiguity about the end date. Whatever you think of the product decision, that is what a communicated shutdown looks like: a date, a commitment, and enough runway between the two for people to act on it.

The alternative to a plan is a slow abandonment

The failure mode is not usually a team deciding to abandon a product. It is a team deciding to sunset it, then letting the plan slip because nobody owns it once the "real" work resumes.

Abandonment looks different from a sunset from the inside and from the outside. Inside the team, it looks like a product quietly dropping off the roadmap: updates stop, the on-call rotation for it gets thinner, and nobody schedules the export tooling because there is always something more urgent. From the outside, it looks like a service that used to work and now does not, with no notice and no way to recover what was in it. Users do not experience the difference between "we decided to sunset this" and "we stopped paying attention to this." They experience a thing that used to work and no longer does.

The fix is treating the sunset plan the way you would treat a launch plan: written down, with an owner, a checklist for the export and migration path, and a date on the calendar that the team is accountable to as a group, not to whichever engineer happened to build the thing originally.

The decision rule, in one pass

Add up what a product costs to keep alive this month. Put that next to what it earns and how many people actually use it. If the cost is out of proportion to the return, that is your answer, and it does not need to be dressed up as anything more complicated.

What takes the actual discipline is everything after the decision: the export that works, the migration path if one exists, and the date announced with enough notice that people can act on it. A product that gets shut down with all three is a sunset. A product that just stops getting updates is what happens when nobody made a decision at all.

The teams that get this right treat the ending of a product with the same care they gave its start. That discipline, not the decision itself, is what a user actually remembers.

Sources

Gematsu, "Stadia to shut down on January 18, 2023; all purchases to be refunded": confirms the announcement date, the final shutdown date, and the refund commitment used as the sunset-mechanics example.