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 way to move to something that still works, and setting a real shutdown date.

How do you decide when a product should be shut down?

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 work, security patching) is higher than its revenue and its active usage is low and falling, that is the sign to plan a shutdown rather than keep paying for it by default.

What counts as "maintenance cost" for this decision?

It is every ongoing cost tied to keeping the product running: 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 quick check is asking how many hours a month the team spends on it and multiplying by what that time is worth doing instead.

Is it enough to 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 planned shutdown and abandoning a product?

A planned shutdown gives users advance notice, a way to export their data, a way to move to another product if one exists, and a firm date, all communicated before anything stops working. An abandoned product just stops getting updates, breaks quietly over time, and users find out when something they relied on no longer works, with nothing to move to and often no way to get their data.

How much advance notice should a shutdown 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, which is longer than the minimum a rule requires. 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 shutdown plan include a way for existing users to move to another product?

Where one is possible, yes. Directing users to 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 shutting it down?

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

Who should be accountable for a shutdown going well?

The team that owns the product, not one individual. A shutdown plan should be a written document with a way to export data, a way to move to another product, 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 used 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 (shut down in a planned way, with notice, a data export and a set date) share one thing: the team separated two questions that usually get mixed together. What does this cost to keep running? And what is it actually returning, in revenue or in real, active usage? Answer those separately, compare them, and the shutdown decision is based on numbers instead of feelings. What follows is that decision rule, and the operational plan that keeps a planned shutdown from turning into a product that is simply left to fail.

Start with the true cost of keeping it running

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 alerts it sends to the engineer on call. 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. An approximate total, added up honestly, is enough to compare against what the product returns.

The part teams miss most often is the cost of keeping it up to date. A dependency with a known vulnerability has to be fixed now, even when the team is busy. 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 work is not on any roadmap, but it appears on every on-call schedule until the team either invests in the product properly or shuts it down.

Compare that cost with usage and revenue, and leave feelings out

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 shutting down are the ones where the maintenance cost is out of proportion to the return: a feature that takes real engineering time every month, that creates support work, and that a small and shrinking group of people actually use.

This is also where feelings are kept out of the decision. A product can be loved by a small group of users who speak up often 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 agree, 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 end. A product with steady usage but no direct or indirect revenue, and a support queue that keeps growing, might be the one to shut down even though the usage chart looks good. Neither number decides alone. 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 numbers point to a shutdown, 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 release something new.

A well-planned shutdown has three parts, 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 answering support tickets instead of giving people time to leave in an orderly way.

A way to move to another product, if one exists. If there is a replacement, your own product or someone else's, direct people to it instead of leaving them with an export file and nowhere to go. If there genuinely is no replacement, say that plainly rather than implying there is an option that does not exist.

For a business tool, a way to move usually means more than a link to a competitor. It means documenting the fields in your export well enough that a user can match them to the fields of 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 move plan that is only one 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 shuts down.

A real date, communicated early. Google's shutdown of Stadia is a useful example of the steps 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 period 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 time between the two for people to act on it.

Without a plan, a product is slowly abandoned

The usual failure is a team deciding to shut a product down, then letting the plan be delayed because nobody is responsible for it once the "real" work starts again.

An abandoned product and a planned shutdown look different, to the team and to users. Inside the team, abandonment looks like a product quietly disappearing from the roadmap: updates stop, fewer engineers are on call for it, and nobody schedules the export tool 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 shut this down" and "we stopped paying attention to this." They experience a thing that used to work and no longer does.

The fix is treating the shutdown plan the way you would treat a launch plan: written down, with an owner, a checklist for the export and the move to another product, 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 short

Add up what a product costs to keep running 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 made to look more complicated.

What takes real effort is everything after the decision: the export that works, the way to move to another product if one exists, and the date announced with enough notice that people can act on it. A product shut down with all three has had a planned shutdown. 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. Users remember that care more than the decision itself.

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 example of how to run a shutdown.

How to decide when to sunset a product