How Do You Sunset a Product Without Losing the Customer?

How Do You Sunset a Product Without Losing the Customer?

By treating it as a migration you are selling rather than an announcement you are making. The customer's question is never why you are stopping. It is what happens to their work, their data, their price, and their contract. Answer those four before you send anything.

Most sunsets we watch go wrong in the same way. Engineering decides the end of life date, marketing writes a polite email, and nobody has decided what the customer is supposed to do next. The customer then decides for themselves, and sometimes that decision is a competitor.

This is the playbook we work through with clients. It is deliberately front loaded, because the decisions you make before the first email determine how the whole thing goes.

Why Is Sunsetting a Go-to-Market Problem, Not a Product One?

Because every part of it that actually risks revenue sits outside the product. Contracts, pricing, sales conversations, support load, and the story you tell the market. The engineering work of turning something off is usually the easy part.

The clearest sign a team has got this backwards is when the end of life date is announced before the replacement is priced. That sequence guarantees an awkward second announcement, and the second announcement is the one customers remember.

It also affects people who are not customers. Prospects in your pipeline will hear about it. Competitors will reference it. Analysts and review sites will note it. All of that is market facing work, which makes it a go-to-market function whoever ends up doing it.

The product side is narrower than it looks: keep it working, keep it secure, and do not degrade it quietly in the meantime. Degrading a product you have announced you are retiring is the fastest way to turn a managed migration into churn. Our piece on deprecating a feature in the product covers that half.

How Much Notice Should You Actually Give?

Longer than feels necessary, and the large vendors have published numbers you can benchmark against. They are not arbitrary, and they scale with how hard the change is for the customer.

Microsoft's Modern Lifecycle Policy sets two different periods for two different situations. For a change where action is required, its policy is "to provide a minimum 30 days' notification when customers are required to take action in order to avoid significant degradation to the normal use of the product or service."

For an actual retirement with nothing to move to, the commitment is far longer. Microsoft states it "will provide a minimum of 12 months' notification prior to ending support if no successor product or service is offered," with an exclusion for free services and preview releases.

And for some cases it goes much further still. The same policy says that for select Azure services under this policy, Microsoft "may provide notification up to three years prior to reaching the end of applicable support."

At the other end of the range, Anthropic's model deprecation policy commits to "at least 60 days' notice before model retirement for publicly released models." That is a shorter window, and it fits a situation where a documented replacement already exists and the migration is a configuration change.

What Does the Notice Period Depend On?

Three things. Whether a replacement exists, how much work the migration is for the customer, and whether the product sits inside something the customer ships to their own customers. The third one is the multiplier everyone underestimates.

If your product is embedded in your customer's product, your sunset becomes their roadmap item, and their roadmap is planned quarters ahead. A 60 day notice that works fine for an internal tool is impossible for something their own release depends on.

Situation	Notice we would plan for	Why
Drop-in replacement, configuration change only	Two to three months	Work is small and the path is documented
Replacement exists but data must move	Six months	Customer needs a project slot, not an afternoon
No replacement from you at all	Twelve months	They have to evaluate and buy something else
Embedded in the customer's own product	Twelve months and up	Their release cycle sets the pace, not yours
Free tier or preview only	Shorter, stated clearly up front	Nobody built a business on a preview, and the terms should have said so

Pick from the top of the range rather than the bottom. A notice period that turns out to be generous costs you a few months of maintenance. One that turns out to be tight costs you accounts, and it costs them loudly in public.

Who Needs to Be Told, and in What Order?

Your own team first, then the accounts with the most at stake, then everyone else, then the market. Getting this order wrong is the most common self inflicted wound in a sunset.

Support and sales need to know before any customer does, with answers to the obvious questions written down. A customer who learns about it from an email and then calls support to find nobody has heard of it has just learned something worse than the sunset itself.

Then the named accounts, by a human, on a call. Not an email. Your largest and most exposed customers should hear it from someone who can answer their specific questions about their specific contract, and they should hear it before the general announcement.

Then the broad notification, then the public page. The public page matters more than people expect, because it is what prospects and competitors will find, and it is what you will point at for the next year.

What Should the Migration Offer Include?

A destination, a path, a deadline, and something that makes moving early better than moving late. Three of those are obvious and the fourth is what determines whether anyone actually moves before the last month.

Without an incentive, every customer migrates in the final two weeks, which is the worst possible outcome for your support team and for their experience. Give them a reason to go early: a price hold, migration help included, a feature they want, or simply a guaranteed hands on session that will not be available in the rush.

The path needs to be specific to their situation, not a generic guide. For your top accounts, that means a named person and a plan with dates. For the long tail, it means documentation good enough to follow without asking, which is a real writing project and should be scoped as one.

Be explicit about what does not carry over, early and in writing. The worst moment in any migration is a customer discovering after the cutoff that something they relied on did not come with them.

How Do You Price the Replacement?

Not higher, at least not at the moment of migration. Combining a forced move with a price increase reads as an ultimatum, and customers respond to ultimatums by going to market.

Hold their effective price through the migration, then have the pricing conversation later as a separate event with its own justification. Separating the two costs you a quarter or two of revenue and preserves the relationship, which is usually the better trade. Our piece on raising prices with existing customers covers doing the second conversation properly.

If the replacement genuinely costs you more to run and the price has to rise, say so plainly, show the mechanism, and give a longer transition. Customers tolerate honest economics much better than a price change presented as a natural consequence of a change they did not want.

Watch the contract mechanics too. Multi year agreements, auto renewals, and any commitment that extends past your end of life date need a decision before the announcement, not a scramble afterwards.

What Do You Do About Customers Who Will Not Move?

Decide your answer in advance, and make sure it is the same answer for everyone in the same situation. There will always be a group who do not migrate, and improvising per account is how you end up maintaining a product forever for three customers on different private terms.

The options are narrow and all of them are legitimate. Extend the date once, publicly, for everyone. Offer a paid extended support arrangement with a clear end. Help them move to a competitor gracefully. Or hold the date and accept the churn.

What we would avoid is the quiet indefinite exception, because it never stays quiet and it never stays one. Once one account has a private extension, your end of life date is no longer real, and every future sunset will be negotiated rather than announced.

Helping someone leave well is undervalued. A customer you migrated politely to a competitor talks about you differently than one you stranded, and in B2B markets those conversations come back.

What Does the Website Need to Say?

One page that states what is ending, when, what to do, and what happens if you do nothing. Dated, linked from the product's own pages, and left up long after the date passes. That page is doing real work for a long time.

Leave it up because people keep arriving. Prospects researching you, customers finding an old link, and engineers at other companies checking whether an integration still works. A missing page means they conclude whatever they like.

Take the retired product out of your current marketing at the same time, properly. Stale pages selling something you no longer offer generate support tickets, waste sales time, and make the site look unmaintained.

If you publish a roadmap, the sunset belongs there too, not only in an email. Our piece on publishing a product roadmap covers how much to commit to in public.

What Would the First Two Weeks Look Like?

Week one is decisions, not communication. Fix the date, the replacement, the pricing stance, the contract handling, and the answer for customers who will not move. Write all five down on one page and get the leadership team to agree to it.

Week two is preparation. Brief support and sales, write the public page, draft the migration documentation, and schedule the calls with your named accounts. Only after those exist does anything go out.

The temptation is always to announce earlier to get ahead of a leak. Resist it by a week or two. An announcement with unanswered questions creates more damage than a slightly later one that answers everything.

If you are planning a sunset and want help with the customer facing side of it, from the migration content to the pages that carry the message, we are happy to help. You can find us at phoenix.studio.