Grandfathered pricing: when to use it and when to sunset it

You're about to raise prices, and the first question that comes up in the planning meeting is never about the new number. It's about the customers already paying the old one. Do you move them to the new plan? Let them keep what they signed up for? Half the room wants to protect revenue, the other half wants to protect the relationship, and most companies resolve the argument by picking "grandfather everyone, forever" and never revisiting it. That default feels safe. It usually isn't free.

Quick answer

Grandfathered pricing means letting existing customers keep their current rate or plan when you change pricing for new customers. It reduces the churn risk of a price change, but if it's left open-ended, it quietly caps average revenue per account, complicates your billing logic, and leaves you unable to answer a basic question: how much annual recurring revenue is sitting on a price book you no longer sell. The fix isn't to avoid grandfathering. It's to treat it as a time-boxed policy with a review date, not a permanent exemption.

What grandfathered pricing actually means

Grandfathered pricing is the practice of holding a customer's existing rate, plan, or terms steady while everyone who signs up after a certain date gets the new pricing. It's the most common way SaaS companies handle a price increase, a repackaging, or a move to a new pricing model, because it lets you change what you charge new customers without an uncomfortable renegotiation with everyone who's already paying you.

It works because it removes the immediate churn risk from the conversation. Nothing changes for the customer on the day you announce it, so there's nothing to react to. That's also exactly why it's easy to leave in place indefinitely: there's rarely a forcing function that brings the decision back up for review.

Why grandfathering becomes the default, and why it quietly costs you

The root cause: pricing logic that can't run two price books cleanly

Most billing setups are not built to run an old price book and a new one side by side, segment which customers are on which, and manage a clean migration path between them. When pricing lives as hardcoded logic in the application rather than as configuration in a pricing engine, every plan version becomes a permanent fork that engineering has to keep supporting. Grandfathering forever isn't usually a strategic choice. It's the path of least resistance when running two price books at once is an engineering project rather than a policy setting.

The hidden cost: ARPU and NRR drift below where they should be

An open-ended grandfather clause protects the customers you already have, but it puts a ceiling on how much revenue they'll ever generate. Baremetrics has flagged this specific tradeoff directly: raising prices for new customers only keeps monthly recurring revenue growing and keeps existing customers happy, but it can quietly work against average revenue per user, since the improved rate only shows up in ARPU for the customers who joined after the change.[1] Multiply that gap across a few price changes over a few years, and a meaningful share of your customer base can end up permanently below the value your product now delivers, which shows up later as compressed net revenue retention rather than as an obvious, single line item. The same mechanics show up in our breakdown of average revenue per account.

The revenue-visibility problem: nobody can say how much ARR is frozen

Ask most RevOps teams how much annual recurring revenue currently sits on grandfathered pricing, separate from current pricing, and the honest answer is usually "we'd have to pull that from a billing export and reconcile it manually." That's a symptom of the same underlying issue: without real-time revenue reporting that can segment by price version, legacy pricing becomes invisible until finance goes looking for it during a fundraise or a board review, which is the worst time to discover it.

Four ways to handle existing customers when you change pricing

There isn't one correct answer here. Monetizely's pricing consultants frame this as a spectrum rather than a binary choice between grandfathering and forced migration, and recommend segmenting customers rather than applying one policy to everyone.[2] In practice, most companies choose from four patterns.

Permanent grandfather

Existing customers keep their exact rate indefinitely. This is the simplest to communicate and the lowest churn risk in the short term. It's the right call for a small, high-value, or strategically important segment (an early design partner, a logo you want as a reference customer) where the relationship is worth more than the pricing gap. It's the wrong default for your entire customer base, since it permanently caps what a growing share of your revenue can be worth.

Time-boxed sunset

Existing customers keep their rate for a defined window, typically 6 to 12 months, with a clear end date communicated up front. This is the pattern that shows up most often in current guidance on price changes, because it gives customers the psychological safety of "nothing changes today" while still building toward full migration on a known timeline.[1] It requires the most planning: a communication cadence, a defined sunset date, and a workflow that actually executes the migration when the date arrives instead of quietly sliding another quarter.

Feature-gated grandfather

Existing customers keep their current price, but new features and capabilities are only available on the new plan. This avoids a direct price conversation entirely. Customers self-select into the new pricing when they want something new enough to be worth paying for, rather than being told their existing plan now costs more. It works best when your roadmap is genuinely shipping things customers want, and works poorly if the new tier's added value is thin. This is the same boundary question covered in how to decide what belongs behind a paywall.

Migrate with an incentive

Move everyone to new pricing, but soften it with a temporary discount, an extended notice period, or a value-add (a free module, an extra seat, priority support) for a limited time. Monetizely points to the general finding that customers accept a price increase more readily when they can see added value attached to it rather than a bare number, and that the size of the increase matters more than whether it's framed as fair.[2] This is the highest-effort option to execute well, and the one most likely to actually close the revenue gap grandfathering leaves open.

How to decide which approach fits your business

A few questions tend to sort most companies into the right lane:

• How big is the price change? Small adjustments (a few percent) rarely need grandfathering at all. Larger increases, a repackaging, or a move to a new pricing model (say, from seat-based to usage-based) are where grandfathering earns its place, at least temporarily.
• How concentrated is the affected revenue? If ten accounts represent most of the ARR on old pricing, a targeted conversation with each one beats a blanket policy. If it's spread across hundreds of small accounts, a time-boxed sunset with clear self-serve communication scales better than individual outreach.
• Can you actually segment and communicate to the right cohort? This is where the plan usually breaks down in practice, not in the strategy meeting. If you can't cleanly identify who's on legacy pricing, model what migrating them would do to NRR, and trigger the right sequence of emails and in-app messages on schedule, "time-boxed sunset" turns into "permanent grandfather" by default, because nobody revisits it.
• What's the actual churn risk if you migrate this cohort now? Not every legacy customer carries the same risk. A churn-risk score that already reflects usage and payment behavior tells you which accounts to migrate first with confidence, and which ones deserve a longer runway or a direct conversation before their rate changes.

Making grandfathering a policy, not a spreadsheet

The reason grandfathering tends to become permanent by accident isn't that founders and RevOps leads don't know the tradeoffs. It's that executing anything other than "leave it alone forever" requires infrastructure most billing stacks don't have: a pricing engine that can run old and new price books side by side without a separate codebase for each, automated workflows that message and migrate the right cohort on schedule instead of waiting for someone to remember, and revenue dashboards that show exactly how much ARR sits on each price version so the decision gets revisited on purpose instead of by default.

That's also why grandfathering shows up so often alongside a broader pricing and tier redesign or a planned price increase: it's rarely a standalone decision. It's one piece of a pricing change that needs the same modular pricing architecture, automated retention workflows, and real-time NRR tracking that the rest of the change depends on, and it's worth testing the migration sequence on a small segment before rolling it out broadly, the same way you'd test any other pricing change before committing to it company-wide.

Frequently asked questions

What is grandfathered pricing? Grandfathered pricing means an existing customer keeps their current rate, plan, or terms after you change pricing for new customers. It's the most common way SaaS companies avoid an immediate churn risk when they raise prices or restructure plans.

How long should you grandfather existing customers? There's no universal number, but a defined window of 6 to 12 months, communicated up front with a clear end date, is the most common pattern in current pricing guidance. Open-ended grandfathering without a review date is the version that tends to quietly become permanent and erode average revenue per account over time.

Does grandfathering hurt ARPU? It can. Grandfathering protects the customers you already have at their current rate, but it means their revenue never reflects the new pricing, which drags down average revenue per user as your new-customer base grows around it. The effect compounds if you grandfather again at the next price change without ever migrating the earlier cohort.

Should new features be grandfathered too, or just the price? Most companies gate new features behind current pricing while keeping the legacy rate for existing plans. That way customers keep the deal they signed up for, but there's a natural, low-friction path to upgrading when a new capability is worth paying for, rather than a direct conversation about raising their price.

What's the alternative to grandfathering everyone? Segmenting customers instead of applying one policy to all of them: grandfather your highest-value or most strategic accounts, put a time-boxed sunset on the broader base, and combine the migration with a genuine value add so the conversation is about what's improving, not just what costs more.

How do I know how much revenue is currently sitting on grandfathered pricing? You need billing and revenue data that can segment by price version or plan vintage, not just by current plan tier. Without that, most teams end up pulling a billing export and reconciling it manually, which is exactly the kind of one-off exercise a real-time ARR breakdown by plan is meant to replace.

Can Stripe alone manage a grandfathering policy? Stripe can maintain a customer on their existing price and subscription indefinitely, which covers the mechanics of grandfathering itself. It doesn't natively give you a cohort view of how much revenue sits on legacy pricing versus current pricing, or trigger a scheduled migration sequence when a sunset date arrives, so most teams end up managing that part in a spreadsheet alongside it.

Sources

1. Baremetrics, "SaaS Price Increase: How to Raise Prices Without Upsetting Customers," by Adam Enfroy, last updated April 23, 2026. https://baremetrics.com/blog/saas-price-increase-how-to-raise-prices-without-upsetting-customers
2. Monetizely, "Grandfathering vs Forced Migration: The Strategic Approach to Price Changes for Existing Customers," May 21, 2025. https://www.getmonetizely.com/articles/grandfathering-vs-forced-migration-the-strategic-approach-to-price-changes-for-existing-customers

Frequently asked questions