How Do You Sunset a SaaS Pricing Plan Without Losing Customers?

How do you sunset a SaaS pricing plan without losing the customers on it?

Give existing customers a long notice period, a clear reason, a recommended new plan, and a price bridge such as honoring their current rate for a set time. Announce it directly, never through a pricing page change they discover alone. Then make the move easy with one click and a named contact for questions.

Every software company eventually has a plan it wants to retire. Maybe it was priced too low in the early days, maybe it no longer matches how the product is packaged, or maybe it creates support work nobody planned for. Retiring it is reasonable. Doing it badly is how loyal early customers become churn.

This article is for a B2B SaaS team with a legacy plan and real customers still on it. I will cover how I would plan the change, what to say, and how to measure whether it worked.

Why do companies retire pricing plans at all?

Companies retire plans when the plan no longer fits the product, the market, or the cost of serving it. Common reasons include a price set before the product matured, a packaging change that makes old tiers confusing, and features bundled in a way that blocks upgrades. The reason shapes how you should explain the change.

Be honest with yourself about which reason applies. If the plan is simply too cheap, the real message is a price change, and customers will see through any language that hides it. If the plan is confusing next to the new lineup, the message is simplification, which customers accept more easily.

Write the reason in one sentence before you plan anything else. If you cannot explain it plainly to your team, you will not be able to explain it to customers, and support will improvise answers that contradict each other.

Should you grandfather existing customers or move everyone?

Grandfather when the plan is small and keeping it costs little, because loyalty is cheap to buy. Migrate when the old plan blocks your packaging, creates real support cost, or holds features you need to charge for. A middle path works well: keep the old price for a fixed period, then move customers to the new plan.

Permanent grandfathering sounds generous, but it piles up complexity. Each legacy plan is another set of rules in billing, another case for support, and another exception in your reporting. A few years of that can leave a small team managing far more pricing variations than it can explain.

The time limited bridge is usually my recommendation. Customers keep their current price for a defined window, such as their next renewal or a set number of months, and then move to the closest new plan. That respects the original deal without freezing your pricing forever.

How much notice should customers get?

Give enough notice that customers can budget and plan, which for B2B usually means at least one full billing cycle and often until their next annual renewal. Longer notice is better when the change raises price or removes features. Short notice on a pricing change reads as a surprise, even if the terms allow it.

Check your contracts and terms of service first. Some agreements specify how much notice you must give before changing prices. Legal minimums are the floor, not the goal. The goal is that no customer feels ambushed.

Annual customers need special care. If someone renews in eleven months, telling them now gives their finance team time to plan. Telling them a month before renewal forces a rushed decision, and rushed decisions often turn into cancellations.

What should the announcement say?

The announcement should say what is changing, when, why, what plan you recommend for them, what it will cost, and what happens if they do nothing. Lead with their situation, not your strategy. Keep it short and specific, and include a direct way to reach a person who can answer questions.

Personalize where you can. A message that says your current plan, your recommended new plan, and your new price is far better than a generic post that makes each customer do the math. Customers should be able to understand their own situation in the first two sentences.

State the default clearly. If they do nothing, will they move automatically to a specific plan on a specific date? Silence about the default creates anxiety and support tickets. I cover similar messaging in how a SaaS should announce a price increase, and most of the same rules apply here.

How do you handle features that disappear with the old plan?

Map every feature on the old plan to where it lives in the new lineup. If a feature moves to a higher tier, say so directly and consider including it for affected customers during the bridge period. If a feature is retired entirely, give a reason, a workaround, and a date, and tell those customers separately.

Feature loss hurts more than price changes. A customer can budget for a higher price. They cannot easily replace a workflow their team depends on. Find out which customers actually use the affected features before you announce anything, so you can speak to them first.

If you are retiring a feature at the same time, treat it as its own communication. My guide to announcing a retired feature to SaaS customers walks through that message in more detail.

How should the migration itself work?

Make the move one click from the announcement, with the recommended plan preselected and the price shown before they confirm. Offer a call for larger accounts. Customers who do not act should move automatically on the stated date. Every extra step in the migration path is a moment where a customer might decide to leave instead.

The worst migration path sends customers to the public pricing page and asks them to figure it out. They see plans they do not recognize, prices without their discount, and features described in new language. That is when comparison shopping starts.

Also watch the downgrade path. Some customers will choose a cheaper plan rather than a more expensive one. That is still a retained customer. Make sure the lower plan is a real option, which I discuss in designing a downgrade flow that keeps the account.

How do you measure whether the sunset worked?

Track the share of affected customers who migrated, the share who downgraded, and the share who churned, compared with your normal churn rate for the same period. Watch support ticket volume and tone during the notice window. Revenue retained from the affected group is the final measure of whether the change paid off.

Set a baseline before you announce. If your usual monthly churn for these customers is known, you can tell whether the sunset caused extra loss. Without a baseline, every cancellation will be blamed on the change, fairly or not.

Read the replies to the announcement. Customers who write back angry are often the ones you can still save with a call. Customers who say nothing and quietly export their data are the ones to worry about.

What should you do next?

List every customer on the plan you want to retire, note their renewal date, contract terms, and which features they use, and write your one sentence reason for the change. Then decide on a bridge period and a recommended new plan for each segment. Only after that should you draft the announcement and the migration flow.

Retiring a plan is a trust test. Customers who joined early took a chance on you. Treating them with notice, clarity, and a fair bridge keeps most of them, and it shows newer customers how you behave when terms change.

If you want help planning a pricing change, the messaging around it, or the automations that move customers between plans in your CRM and billing tools, reach out. I work with B2B SaaS teams on go-to-market and the systems behind it. Let's chat.