How Do You Sunset a Feature Without Losing Customers?

How Do You Sunset a Feature Without Losing Customers?

Announce it before you break it, warn people inside the product where they actually use it, give them a migration path, and remove it only when usage is genuinely small. Most sunsets go badly not because the decision was wrong but because the first time a customer heard about it was when it stopped working.

We design product interfaces as well as marketing sites, and removals come up more often than teams expect. Every feature you ship is a promise you will eventually have to either keep or retire carefully.

This is the framework we use. It borrows shamelessly from how browser vendors do it, because they have had to remove features from the most used software in the world without breaking the web.

Why Do Feature Removals Go Wrong?

Because the team has been living with the decision for months and the customer hears about it on a Tuesday. Internally the removal has been debated, planned and scheduled. Externally it arrives as a surprise, and surprise is what turns an inconvenience into a trust problem.

The second cause is misjudging who uses it. Low overall usage often hides heavy usage by a small group, and that group is frequently your most committed customers, because depth of use is what long-tail features attract.

The third is offering no alternative. "We removed it" is survivable. "We removed it and there is no way to do that any more" is a reason to evaluate competitors, and people will.

What Can We Learn From How Browsers Do This?

A great deal, because their constraint is extreme. Chrome's documentation for developers draws a hard line between the two phases, stating plainly that deprecation is not removal, and defining deprecation as the announcement phase before feature removal, when vendors warn developers that they plan to remove a feature.

The mechanics are worth copying. An intent to deprecate is posted publicly on a mailing list, the feature stays available, warnings appear in the developer tools where engineers will actually see them, and timelines are published on a status site. The feature typically remains available for several versions before being disabled by default.

The removal bar is the part most product teams skip. Chrome's documentation says a feature will only be removed if, for example, it is used by a very small proportion of users and better alternatives are available. Both conditions, not either.

What Is the First Step?

Measure who uses it, not how much it is used. Pull the list of accounts, not the aggregate number, and look at the shape. Ten accounts using it every day is a completely different situation from a thousand accounts using it once a year, even when the totals match.

Then look at what those accounts have in common. If your heavy users of a feature you want to kill are disproportionately your largest contracts, the removal is now a revenue decision, and it needs to be made by people who own revenue.

This step frequently ends the project, which is a success. Plenty of removals are proposed because a feature is annoying to maintain, and the honest answer is that maintaining it is cheaper than the churn.

How Should You Announce It?

Once publicly, once by email to affected accounts, and then repeatedly in the product. A changelog entry alone is not an announcement, because almost nobody reads changelogs, and the people who do are not the ones who will be surprised.

Say four things: what is going away, when, why, and what to use instead. The why matters more than teams think. "We are replacing this with something better" and "almost nobody used this and it was holding back the rest of the product" are both acceptable. Silence is what people fill with worse explanations.

Give a real date, not a quarter. A vague timeline gets ignored, and then the removal is a surprise anyway despite your having technically announced it.

What Should the In-Product Warning Look Like?

It should appear where the feature is used, not in a notification centre. Chrome puts its warnings in the developer tools panel, which is where the person using a deprecated API is already looking. The equivalent in your product is the screen that contains the thing you are removing.

Keep it factual and give it an exit. Jakob Nielsen's usability heuristics, first published in April 1994 and still the most useful checklist in the field, include visibility of system status, which asks that the design always keeps users informed about what is going on through appropriate feedback within a reasonable amount of time. A deprecation banner is exactly that.

They also include user control and freedom, which asks for a clearly marked exit from unwanted actions. In a sunset, that means a link to the replacement and a way to export whatever data the feature holds. Our piece on SaaS notification design covers how to do this without the banner becoming wallpaper.

Should You Degrade Before You Remove?

Usually yes, and this is the step that saves you. Turning a feature off for new accounts while leaving it working for existing ones stops the problem growing while you handle the people already affected.

A second useful stage is making it harder to reach rather than impossible: out of the main navigation, into a settings page, still fully functional. Usage drops, the people who genuinely need it still find it, and you learn who those people are because they are the ones who bothered.

What you should not do is silently degrade the experience. Slowing something down or letting it get buggy as a way of encouraging migration is a choice customers can see, and it damages you more than an honest removal would.

How Long Should the Window Be?

Long enough for a customer's own planning cycle. For a self-serve product with a simple replacement, a few weeks is reasonable. For anything an enterprise customer has built a process or an integration around, three to six months is the honest minimum, because their change has to go through their change management, not yours.

The right way to set it is to ask the affected accounts. A short call with your five heaviest users of the feature will tell you more about the realistic timeline than any internal debate, and it converts the removal from something done to them into something they were consulted on.

Extend once if you have to, and say why. Extending quietly and repeatedly trains everyone to ignore your deadlines, which will cost you on the next removal.

What About the Data?

Give it back before you take the feature away. Anything a customer entered belongs to them, and the removal of the interface should never be the removal of the record.

Export first, in a format someone can actually use. A JSON dump satisfies the letter of this and fails the spirit for a marketing team who needed a spreadsheet. Our piece on import and export UX covers what a usable export looks like.

Keep the data accessible for a period after the interface goes, and say how long. This is the single cheapest thing you can do to make a sunset feel respectful rather than abrupt.

What Does a Good Sunset Look Like in Summary?

Five stages, in order: measure who is affected, announce with a date and a replacement, warn in place where the feature lives, degrade by closing it to new accounts and lowering its prominence, then remove only once usage is genuinely small and the alternative genuinely works.

The test of whether you did it well is not whether anyone complained. Someone always complains. The test is whether the people who complained could have seen it coming, had somewhere to go, and kept their data. If all three are true, you will be fine.

If you are planning a removal and want a second opinion on the communication and the interface around it, we are happy to walk through it. You can reach our team at phoenix.studio.