How to Sunset an AI Feature Without Losing Customers

To sunset an AI feature, decide with usage data rather than opinion, tell the people who still use it before you tell anyone else, keep it running for one full billing cycle after the announcement, and give the remaining users a path to whatever replaces it. The order matters more than the timeline. Most retirement disasters are communication failures, not engineering ones.

AI features get retired more often than other features, for a reason worth naming: many of them were built during a wave of enthusiasm, priced optimistically against inference costs, and shipped before anyone knew whether the demand was real. A good sunset process is the cost of having been willing to experiment.

Decide with three numbers, not a hunch

Before anything else, establish whether this is a retirement or a marketing problem. Three figures settle it.

Weekly active users of the feature, as a share of eligible users. Not total invocations, which one power user can inflate. If under two percent of the people who could use it did so in the last month, you have a retirement candidate. Between two and ten percent, you have a question. Above ten percent, retiring it will hurt.

Gross margin on the feature. Inference cost plus support load against attributable revenue. AI features are unusual in that a lightly used feature can still be expensive, because a small number of heavy users generate real token spend. A feature at one percent adoption and negative margin is an easy call.

Retention correlation. Of the accounts that use it, what share renewed last cycle compared with accounts that did not? A low-usage feature with a strong retention correlation is a feature your best customers depend on, and killing it is expensive in a way the usage number hides completely.

If you cannot produce these numbers, that is the first task. Adding analytics to an AI-built app covers the instrumentation, and it is worth doing before you need it rather than during a decision.

Segment the users you are about to disappoint

Aggregate usage hides the shape of the harm. Split the remaining users into three groups, because each needs a different message.

Personal outreach to the first group is not a courtesy, it is a churn control. It is usually a small list, often small enough to email by hand, and the accounts on it are disproportionately valuable. If somebody built a business process on your feature, they will forgive the retirement and not the surprise.

Write the announcement in this order

The structure that works reverses the instinct to lead with rationale.

1. What is being retired, and the exact date. Specific date, specific feature name, first line. Not "we are evolving our product".

2. What happens to their data. Export path, retention period, deletion date. This is the second question everyone has and burying it reads as evasion.

3. What to use instead. A concrete alternative, including a competitor's product if you genuinely have nothing. Recommending a competitor costs you very little and buys real goodwill.

4. Why. Brief and honest. "Not enough people used it to justify keeping it working properly" is respected. "To focus on our core experience" is not.

5. Who to contact. A human, or at least a monitored address.

Notice that "why" is fourth. Users care about the impact on them; the reasoning is context, not headline.

Two things to avoid. Do not describe a retirement as an upgrade unless the replacement is strictly better for the people losing the feature, which it usually is not. And do not announce a date you have not confirmed with engineering, because moving a sunset date twice destroys the credibility of every subsequent announcement you make.

The timeline that avoids most of the pain

For a paid feature, one full billing cycle between announcement and shutdown is the minimum. Annual contracts need to reach their renewal.

A workable sequence for a monthly product:

• Day 0. Announce. Individual outreach to the dependent group the same day, before the general announcement lands, so they never hear it from a changelog.

• Day 0 to 14. Stop new signups to the feature. Existing users keep full access. Nothing is more irritating than discovering a feature and losing it in the same week.

• Day 14. Export tooling live and documented. If exports need engineering work, this is the deadline that actually constrains the plan.

• Day 30. In-product banner for active users, with days remaining.

• Day 45. Feature becomes read-only. Existing data viewable and exportable, no new processing.

• Day 60. Shutdown. Endpoint returns a clear, specific error naming the retirement and linking to the alternative, not a generic 404.

• Day 60 to 150. Data retained and recoverable on request.

• Day 150. Deletion, if the announcement said so and no legal obligation says otherwise.

That retention window has a compliance dimension for AI features specifically, since prompts and outputs may contain customer content with its own obligations. How long to keep AI chat logs works through the retention question on its own terms.

Pricing and billing, the part that gets forgotten

If the feature was bundled, nothing changes commercially and you should say so explicitly, because customers will assume they are being charged the same for less.

If it was a paid add-on, stop billing for it at the announcement, not at shutdown. Charging for sixty days of a feature you have already announced as dead is technically defensible and universally resented. The revenue is small. The screenshot of the invoice is not.

If it was the reason someone bought the plan, offer a credit or a downgrade path proactively. They will ask otherwise, and asking first is worth more than the money. There is a version of this that turns into churn, which is why the reducing churn on a subscription product playbook is relevant here even though this is not a pricing change.

Sunsets also create the same trust exposure as a price increase, and the mechanics of handling that well transfer directly from raising prices on an AI product.

When the model is retired for you

Sometimes the decision is not yours. A provider deprecates the model your feature is built on, and you inherit a deadline.

Two options, and the choice should be commercial rather than technical. Port to a successor model and eat the behaviour change, accepting that outputs will differ and some prompts will need rework. Or use the forced date as the moment to retire a feature that was already marginal, which is often the right call and rarely the first instinct.

Do not tell users the feature is going away because a vendor deprecated a model. It is true and it is not their problem, and it signals that your product's stability depends on decisions you do not control. What to do when an AI model gets deprecated covers the migration side.

Frequently asked questions

How much notice is enough for a free feature? Thirty days is defensible for a free tier, sixty is generous. The constraint is the same regardless of price: whoever built a workflow on it needs time to build a new one.

Should I keep the feature running for the handful of people still using it? Only if you will keep maintaining it, which means keeping it secure and working when its dependencies change. A feature that exists but silently rots damages you more than an honest retirement.

Can I quietly remove it if nobody uses it? If usage is genuinely zero for a full quarter, a changelog line is proportionate. If it is near zero, announce it properly. The cost of over-announcing is nothing; the cost of surprising your one remaining user, who may be an enterprise account, is not.

What if leadership wants to spin it as a strategic focus? The spin costs credibility with exactly the users who noticed. Retire it plainly, in one paragraph, and spend the communication budget on the replacement instead. Deciding what that replacement should be is a different exercise, covered in our guide to monetisation strategy for AI products.