Should You Change Pricing and Packaging for Existing Customers?

You are changing your pricing. What happens to the customers you already have?

That is the real decision, and it is usually made last when it should be made first. New pricing for new customers is an easy call. What you do with the people who signed up under the old terms determines whether the change reads as a business making a reasonable adjustment or as a company that reprices whenever it feels like it.

The mistake I see repeatedly is treating this as a communications problem to be solved after the pricing is set. It is not. The grandfathering decision changes the revenue model, so it belongs in the same conversation as the numbers.

Here is how I would think it through, with two current examples of software companies handling exactly this in public.

What are you actually deciding here?

Three separate things that get collapsed into one. Whether the price changes for existing customers. Whether the packaging changes for them, meaning what they get for that price. And when either takes effect. These have different answers and different consequences, and deciding them together is how teams end up making a bigger change than they intended.

Packaging changes are often the bigger disruption, and they get less attention because they do not appear on the invoice. Moving a feature from a lower tier to a higher one is a price increase for anyone who relies on it, whether or not their monthly figure moves. Customers experience it that way even if your spreadsheet does not.

Separate the three, decide each on its own merits, and write down which you are actually doing. A change that is genuinely just new-customer pricing is a very different announcement from one that repackages what existing customers already depend on.

Should existing customers be grandfathered?

My default is yes for price, and no for packaging, and I will defend both halves. Honoring the price someone signed up at costs you a known amount of revenue and buys you an enormous amount of trust, and trust is the thing that makes the next change possible.

Packaging is different because keeping old customers on an old feature set means maintaining two products indefinitely. That cost is invisible in the first year and considerable by the third, and it usually lands on the people least able to argue about it, which is your engineering and support teams.

The case against permanent price grandfathering is real and worth stating: it creates a cohort paying substantially below cost as your product grows, and it means the customers who have been with you longest subsidize least. If you go that way, be honest that it is a permanent commitment rather than one you will quietly revisit in two years, because quietly revisiting it is far more damaging than never having offered it.

The middle path I most often recommend is time-boxed grandfathering. Existing price honored for a stated period, then a stated transition. It is less generous than permanent and much more honest than indefinite silence.

How much notice is enough?

Enough for the customer to do something about it, which means enough to evaluate an alternative, get an internal approval, or adjust a budget cycle. For a monthly self-serve product that is weeks. For an annual contract with procurement involved it is a full renewal cycle.

The test I use is simple: could a reasonable customer, told today, actually complete the response you would consider fair by the effective date. If the honest answer is no, the notice period is not notice, it is an announcement.

Announce the date at the same time as the change. A price change with an unspecified effective date creates a period where nobody knows whether to act, and that ambiguity generates more churn than the increase itself.

What can you learn from how software vendors do this in public?

Two current examples are instructive because they are documented on the vendors' own pricing pages rather than in a blog post you have to trust.

Google publishes Gemini 3.8 Flash on its paid tier at 0.75 dollars per million input tokens and 3.75 dollars per million output tokens through 31 December 2026, rising to 1.50 dollars and 7.50 dollars from 1 January 2027. The increase is published, dated, and sitting on the page you consult before you build. Anyone who is surprised in January was not reading. That is the good version: the change is knowable in advance from the artifact customers already use.

Anthropic offers the other half of the lesson. Its pricing documentation notes that the 2 dollars and 10 dollars per million pricing for Claude Sonnet 5, originally announced as introductory pricing through 31 August 2026, is now the standard price, and that the previously scheduled increase to 3 dollars and 15 dollars on 1 September 2026 will not occur. A pre-announced increase was cancelled, and the cancellation was documented in the same place the increase had been.

The transferable pattern is not about who is cheaper. It is that both companies put the change, the date, and the reversal in the artifact customers actually consult. Most small businesses announce a price change in an email and never update the page, which guarantees that half their customers learn about it from a contradiction.

How should you communicate it?

Directly, in one message, from a person, with the number in the first two sentences. Every instinct to soften the opening makes it worse, because a customer who has to read three paragraphs to find out what it costs concludes you were hoping they would not.

Say what is changing, what it costs, when it takes effect, and what specifically happens to them given their current plan. That last part is the one people omit and the one that determines whether they have to email you to find out, which is the outcome you are trying to avoid.

Give a reason, and make it a real one. Costs increased. The product does more. The old pricing did not support the support you want to offer. Customers accept reasons far more readily than they accept a change that arrives with no explanation, and the absence of a reason invites them to invent a worse one.

Then update the pricing page the same day. I argued for putting pricing in public in why I publish my pricing, and the corollary is that a published price you do not maintain is worse than no published price at all.

What should you never do?

Three things. Never change the price without changing the page, because the mismatch is what turns a reasonable increase into a credibility problem. Never make the change discoverable only at renewal, because a customer who finds out from an invoice tells other people how they found out. And never offer a discount only to the people who complain, because you have just taught your customer base that complaining is how pricing works here.

The related trap is the quiet packaging change: moving a feature up a tier without announcement, hoping most people do not notice. Some will not. The ones who do will describe it publicly, accurately, in language you will not enjoy, and they will be right.

Across 70 plus projects for 25 plus clients over 6 plus years, I have never regretted being early and explicit about a price change, and I have regretted delay more than once. The version of this for a services practice is in raising rates with existing clients without churning them.

How do you know whether it worked?

Not by revenue in the first month, which will look good regardless because the increase lands before the churn does. Watch the cohort who received the change against the cohort who did not, over at least two renewal cycles.

Watch three specific things: cancellation rate in the notice window, downgrade rate to a lower tier, and the volume of support conversations that begin with confusion rather than disagreement. That third one is a measure of your communication rather than your pricing, and it is the one you can fix immediately.

Also watch whether new customers are landing on the tier you expected. A repackaging often shifts where people enter, and if everyone now lands one tier lower than your model assumed, the price change has not done what the spreadsheet said it would. Your pricing page carries most of that weight, which is why I treat it as a structural problem rather than a copy one in designing a SaaS pricing page for the AI answer era.

What should you do next?

Write one sentence for each of the three decisions: is the price changing for existing customers, is the packaging changing for them, and on what date. If you cannot write all three cleanly, you are not ready to announce anything, and the ambiguity will show up in the email.

Then draft the customer message before you finalize the numbers. If the message is uncomfortable to write, that discomfort is information about the change itself, and it is much cheaper to act on now than after it is sent.

I work with founders on pricing, packaging and the go-to-market decisions around them, on fixed fees, with most projects landing between 1,000 and 10,000 dollars. If you are about to reprice and the existing-customer question is the part you keep deferring, reach out and let's chat.