You have been selling two or three paid plans for a year or two. Now one of them needs to change: the price goes up, a limit moves, or one plan becomes two. The new customers are easy. The hard part is everyone who already pays for the old version.
Their terms are rarely in one place. The price lives in the payment provider's subscription. The plan name sits in a column in your own database. The limits are checked somewhere in your code. A handful of customers have a discount or a special arrangement that someone agreed to over email. Changing the plan means deciding what happens to all of that for every existing subscriber.
This post walks through what the payment side does and does not do for you, the common ways teams handle existing customers, and the state that tends to get lost when they are moved.
What the payment side does when a price changes
Using Stripe as the example, since its behavior is documented in detail, a few facts from its documentation shape every option below.
A price cannot be edited. Once a price object exists, its amount is fixed; only fields such as its metadata, nickname and active flag can change. Changing what a customer pays means creating a new price and moving the subscription to it (Manage products and prices).
Retiring a price does not move anyone. Archiving a price stops new purchases of it. Existing subscriptions on that price stay active until they are cancelled. Taking an old plan off sale leaves every current subscriber exactly where they were.
Moving a subscription is an explicit step, with two details to get right. To switch a subscription to a new price you name the subscription item being replaced; otherwise the new price is added alongside the old one and both are billed. The quantity also resets to one unless you pass it again (Change the price of existing subscriptions).
Proration covers money paid in advance, not usage. A mid-cycle change is prorated by default: the rest of the period is charged at the new price. You can preview this or turn it off, and a negative proration is not refunded automatically. Stripe's documentation states that usage-based billing is not subject to proration (Prorations). If you want the switch to happen at the end of the period instead, the documentation points to subscription schedules.
That last point matters most for this post. The payment side settles the money for the part of the period already paid for. What happens to the customer's usage counts, remaining allowance and limits when the plan changes is not decided there. Wherever those numbers live, deciding what happens to them is your call.
Ways to handle existing customers
None of these is the right answer in general. Each has people who argue for it in public, and each has a cost.
Keep them on the old plan
The old plan stops being sold, and everyone already on it keeps their price and limits for as long as they stay. One software company wrote publicly, when it retired a product, that it would take no new users but would look after the existing ones forever.
This is the simplest thing to tell customers, and the payment side already behaves this way when you archive a price. The cost builds up on your side. Each plan you keep is another set of limits your code has to recognize, another row in every report, and another case to test when you change anything nearby. Customers on the same features end up paying different amounts. One founder has written that, two years after keeping existing customers on their old pricing, a noticeable part of their revenue came from plans they no longer sold, and that the extra plans added operational complexity.
Move them at their next renewal, with a window to lock in
The new price applies from each customer's next renewal after a set date. Some teams also offer a window before that date: renew early, or switch to annual billing, and keep the old price for one more term. A team chat product took this approach for its first price increase in 2022, according to reporting at the time.
This spreads the change across a full billing cycle, and nobody is moved in the middle of a period they have already paid for. It also means that for months you are running both the old and the new terms at once, and each customer's switch date depends on when they last renewed.
Move them to the new price with an explicit discount
Instead of keeping the old plan, you move everyone to the new one and give existing customers a discount on it, stated as a loyalty discount. One pricing-analytics founder has argued for this in a talk, as later summarized by an investor: since price increases are inevitable, avoid leaving customers on legacy pricing, and give existing customers a loyalty discount on the current plan instead.
You end up with one plan to maintain and one set of limits. The discount, though, becomes a long-lived piece of state of its own, which leads to the next section.
Move them now
The change applies to everyone at once. Mid-cycle, the payment side prorates the money by default. Everything that is not money (usage so far this period, what is left of an allowance, any customer-specific limits) has to be carried across by you.
This gets everyone onto the same terms fastest. It also puts the most state in motion at a single moment, and the customer notices the change in the middle of a period.
Variations
Teams often mix these. Light users might be moved at once while heavy users get a longer window, or a plan's price might be held while its limits change. Each variation adds a rule that has to be applied correctly to every subscriber, so it helps to write the rules down before deciding which customers fall under which.
Old prices you cannot see
Not every old price shows up as an old plan. Discounts are a common place for one to hide.
In Stripe, a coupon can apply once, for a number of months, or forever. If a coupon is set to apply forever and also has an expiry date, the expiry date only stops new customers from redeeming it; anyone who already has it keeps the discount forever. Deleting a coupon stops it from being applied to new subscriptions and invoices, but it does not remove it from subscriptions and invoices that already have it (Coupons and promotion codes).
So a launch promotion that "ended" years ago can still be lowering what some customers pay today, under a plan whose list price you have since raised. Changing the subscription's discount does not trigger proration either; the new discount applies from the next invoice. Before a price change, it is worth listing every discount still attached to an active subscription, not only the ones you can still issue.
The state that gets lost when you move customers
When a customer moves from one plan to another, four kinds of state need a decision, and they are easy to miss because none of them is the price.
- Consumed counts. How much the customer has already used this period. Does it carry over against the new limit, or reset?
- Unused balances. Prepaid amounts or credits the customer has not spent yet. Do they move across at the same value, convert, or expire?
- Remaining allowance. What is left of a quota under the old plan. If the new plan's limit is lower than what the customer has already used, what happens on the first request after the switch?
- Per-customer overrides. The higher limit someone was given as a favor, the feature turned on for one account, the arrangement made during a sales call. These are usually the least documented and the most likely to be overwritten by the new plan's defaults.
For each of the four, it is worth deciding in advance what happens to a customer who is moved now, at renewal, or not at all, and checking that every place that stores the number agrees with the decision.
Estimating the impact before you change anything
Before choosing an approach you usually want to know how many customers each option affects and by how much. If that estimate comes from exporting subscriptions into a spreadsheet, keep in mind what the export does not contain. It is a snapshot of the payment side at one moment. It will not show usage, remaining allowances or overrides kept elsewhere, and it is out of date as soon as anyone subscribes, upgrades or cancels. The estimate is only as complete as the sources joined into it.
Telling customers is part of the plan too. Your own terms, and the law where your customers are, may require advance notice of a price change; check with whoever is responsible for your terms before you set dates.
A checklist before you change a plan
- Decide which approach applies to which customers: keep, move at renewal, move with a discount, or move now.
- Create the new price; do not expect retiring the old one to move anybody.
- When switching subscriptions, name the item being replaced and pass the quantity.
- Decide whether a mid-cycle switch is prorated, and remember that proration covers prepaid money, not usage.
- For each of consumed counts, unused balances, remaining allowance and overrides, write down what happens on the switch.
- List every discount still attached to an active subscription, including ones that can no longer be redeemed.
- Check that the plan recorded in your database, the limits in your code and the subscription in the payment provider all agree for a sample of customers after the change.
ShipRev is being built to keep a SaaS product's identity, subscriptions, metering and entitlements on one customer record. It has not been released, and this post describes a situation teams face, not something ShipRev does today.