How do you handle grandfathering when changing prices in 2027?

The renewal that forces the question

Picture a $14M ARR vertical SaaS company that has not touched list price in four years. Support costs per seat have climbed, the product now ships three modules that used to be add-ons, and the new-logo team is closing at a 22% average discount off a list price that was set when the product did half as much. Finance models a 19% list increase for the 2027 selling year. The moment that model leaves the CFO's laptop, the real question arrives: what happens to the 640 customers already on the books?

That is where grandfathering stops being a pricing footnote and becomes an operations project. The 640 accounts are not one population. Roughly 40 of them are strategic — multi-year, executive-sponsored, with procurement teams that will read the MSA line by line. Another 180 sit in a mid-market band where the CSM knows the champion by first name and the renewal is a fifteen-minute call. The remaining 420 are small, self-serve-adjacent, month-to-month or annual auto-renew, and most of them will never speak to a human about the change. Applying one grandfathering rule across all three groups guarantees you either overpay the small accounts in forgone revenue or under-protect the large ones and lose a logo that took eighteen months to land.

The second thing that surfaces is contractual reality. A price increase is only a decision where you have the right to make it. Multi-year contracts with locked rates are not a grandfathering question at all — you are legally obligated to honor them until expiry, and the only lever is what happens at renewal. Annual contracts with a price-escalation clause tied to CPI or a fixed 3–7% band mean grandfathering applies only to the portion of the increase above that clause. Auto-renewing agreements in several US states carry statutory notice requirements before a material change. So the first work order is not "design the policy" — it is "pull every active contract and sort it into: locked, escalation-capped, freely adjustable." That audit, done properly by a RevOps analyst with a decent CPQ or CLM export, takes two to four weeks and it determines the size of the addressable increase before a single customer email goes out.

The third surprise is billing. A grandfathering policy is a promise that your billing system has to keep for two years without human babysitting. If your platform can only hold one active price per SKU, "grandfathering" collapses into a manual override table that someone maintains in a spreadsheet and eventually forgets — which is how companies end up with customers still paying 2023 rates in 2029. Before you promise anything to customers, confirm the system can carry a legacy price book, tag accounts to it, and fire an alert when a grandfather window expires.

How the mechanism actually works

Grandfathering runs as a decision tree with four terminal structures, and the useful move is to decide which structure each segment gets *before* anyone talks to a customer, so CSMs are negotiating within a policy rather than inventing one per call.

Simple grandfathering is the default: existing customers keep current pricing until their next major renewal, typically 12 to 24 months out. New customers pay the new rate from day one. It is operationally the cheapest to run — one flag on the account, one expiry date — and it is the right answer for the long tail where the per-account revenue at stake is smaller than the cost of a negotiation.

Graduated grandfathering splits the increase across two cycles: roughly half the increase at the first renewal, the balance at the second. This is the structure for the mid-market band where a 19% jump in one step triggers a budget conversation the champion cannot win, but a 9% step is absorbable inside an existing line item. The cost is billing complexity — you now need two scheduled price changes per account, and if your system cannot schedule the second one automatically it will not happen.

Multi-year grandfather extension is the structure most worth engineering deliberately. The customer commits to a two- or three-year term; in exchange, they hold today's rate for the length of that term. Both sides get something real: the customer buys price certainty through a period of announced increases, and you convert an annual renewal into contracted, forecastable revenue. This is the offer to put in front of enterprise accounts first, because it turns a defensive conversation into a commercial one.

No grandfathering with a retention credit moves everyone to the new price at once and offsets the first year with a one-time credit or a service concession. It is the aggressive path, and it is defensible in exactly one situation: when maintaining parallel price books would cost more in operational drag than the churn you would prevent. Small, high-volume, low-ACV bases sometimes fall here.

Two governance details make this tree hold up under pressure. First, define the CSM's standing authority explicitly — for example, a CSM may extend a grandfather window by up to six months or hold a rate for one extra cycle without asking anyone. Anything beyond that goes to VP CS or RevOps. Without a written boundary, every account becomes an escalation and the policy dissolves into whoever negotiates hardest. Second, log every non-standard arrangement as a contract amendment or a countersigned letter, not as a note in the CRM. The amendment is what your auditors will ask for, what revenue recognition depends on, and what protects you when the champion who agreed to it leaves.

Timing is the other half of the mechanism. Notify roughly 90 days ahead of the affected renewal. Inside 60 days you are compressing a budget conversation into a period where the customer has no room to plan, and it reads as a squeeze. Beyond 120 days the notice arrives with no urgency attached, gets filed, and you re-explain everything anyway. Sequence the communication too: existing customers hear first by direct email and in-app notice, and the public pricing page updates after that window closes. A customer who learns about their own price increase from your website has already decided how they feel about it.

Real numbers, ranges, and benchmarks

The parameters that recur across published SaaS pricing guidance and practitioner surveys are consistent enough to plan against, provided you treat them as ranges rather than laws.

Grandfathering window. Twelve to twenty-four months is the common band, with 12 months standard for annual contracts and 24 to 36 months appearing where multi-year terms are involved. The window should map to renewal cycles, not to calendar convenience — a window that expires mid-term forces an awkward off-cycle conversation.

Notice period. 60 to 90 days is the operating norm, and several US auto-renewal statutes set a floor in that same neighborhood for material changes to consumer-facing subscriptions. Check the specific requirements in California, New York, and Illinois if any portion of your base is consumer or prosumer.

Escalation clauses. Where an MSA already permits annual uplifts, the contracted band is usually 3–7% per year, often CPI-linked. If your standard paper has a 5% clause and you are raising list 19%, only the 14-point delta is genuinely at issue for those accounts — which shrinks the grandfathering population meaningfully and is worth calculating before you assume the whole book needs a policy.

Implementation runway. Announcement to full rollout typically runs six to nine months. Inside that: two to four weeks for the contract audit, four to six weeks for billing configuration and testing, and two or three enablement sessions for CS, Sales, and Support spread over a couple of weeks. The billing work is the item that slips, because it usually requires someone to build a legacy price book and account-attribute logic that has never existed before.

Modeling the trade. Take a $10M ARR base, a 20% list increase, and 80% of existing revenue grandfathered for twelve months. The forgone incremental revenue in year one is roughly $1.6M — that is the number the CFO will see first, and you should put it on the slide yourself rather than let someone else find it. The offsetting case is churn avoided: if the unprotected path would push logo or revenue churn into the high teens and the protected path holds it in the mid single digits, the retained revenue is the same order of magnitude, and the LTV difference compounds past year one because a retained account renews again at the *new* price. Run this with your own churn elasticity if you have it; if you do not, run it as a sensitivity table across a 5%, 10%, and 20% churn assumption and let the board pick which one they believe.

Expected uptake. When a multi-year rate lock is offered alongside the standard path, a meaningful minority of accounts take it — enough that you should staff for the contracting work, not treat it as an edge case. The accounts that take it skew toward those with predictable usage and a procurement function that values budget certainty. Accounts in a growth curve often decline, because locking a rate also locks them out of renegotiating as they expand.

Track the program with a small dashboard rather than a quarterly deck: count of accounts under grandfathering, ARR under legacy pricing, churn rate by segment against the pre-change baseline, conversion rate at window expiry, and net revenue retention. Review it monthly during the transition. The signal to watch is divergence between segments — if mid-market churn runs several times enterprise churn, the mid-market structure is wrong and you can fix it mid-flight by extending that band or adding a credit, which is far cheaper than discovering it in the annual review.

Trade-offs, adjacent plays, and what else moves

Grandfathering is one instrument in a set, and it is often not the best one for a given segment. The alternatives are worth pricing against each other honestly.

Packaging change instead of a price change. Rather than raising the price of the existing SKU, move capability between tiers so the current tier stays at the current price with less in it, and the new tier carries the increase with more. Existing customers keep their price and their features via a legacy tier; the increase lands entirely on new business and on upgrades. This avoids the grandfathering apparatus almost entirely, at the cost of a permanent legacy tier you will maintain for years and a catalog that grows a barnacle every time you do it.

Uplift clause instead of an event. Rather than a one-time increase, add a contractual annual uplift of 3–5% to all new and renewing paper. The increase becomes a scheduled, expected, boring line item. This is the structurally healthiest answer and the slowest — it does nothing for the price gap you already have, and it only reaches the whole base after a full renewal cycle. Most companies doing a large one-time correction should also be adding the uplift clause, so they never have to do the large correction again.

Usage or seat-band repricing. If the increase is really about cost-to-serve concentrated in heavy users, raising the entry price punishes the wrong accounts. Repricing the overage rate or the top seat band lands the increase where the cost is and leaves most of the base untouched, which shrinks the grandfathering population to a handful of accounts you can handle individually.

Grandfather the price but not the terms. A frequently missed middle path: hold the rate, but require the customer to move onto current paper — current SLA, current MSA, current auto-renewal and notice provisions. Legacy pricing is expensive; legacy *contracts* are worse, because they carry indemnities and termination rights you stopped offering for good reasons. Trading a rate hold for a paper refresh is often the single most valuable concession available.

The downstream effects deserve planning too, because they land on teams that were not in the pricing meeting. Sales compensation breaks quietly: if quota credit is based on ACV and a rep's renewal book is grandfathered, that rep carries a quota built on new pricing against a book that legally cannot reach it. Adjust quota or credit the grandfathered delta, or you will lose renewal reps during the transition. Forecasting breaks because the same SKU now has two or three realized prices and pipeline math built on list assumptions drifts. Partner and reseller agreements frequently reference list price directly and may need their own amendment cycle running in parallel. Support and onboarding will field the "why did my price change" ticket volume, and they need the same one-page answer the CSMs have — inconsistent explanations between channels do more damage than the increase itself.

Common pitfalls and how to avoid them

Grandfathering with no end date. The most common and most expensive failure. Someone writes "existing customers keep current pricing" without specifying until when, and five years later a nontrivial slice of ARR sits on prices nobody alive set. The fix is mechanical: every grandfathered account gets a stored expiry date, and the billing or CRM system fires an alert 90 days before it. If your system cannot store that date, the policy is not implementable — fix the system first.

One rule for the whole base. Applying simple grandfathering to a strategic account wastes an opportunity to trade a rate hold for a multi-year term. Applying bespoke negotiation to 400 small accounts consumes CS capacity you do not have. Segment first, and write down which structure each band gets before the first call.

Notifying too late. Under 60 days reads as a squeeze and gives the champion no time to secure budget. It converts a routine increase into an escalation and, in some jurisdictions with auto-renewal statutes, into a compliance problem.

No multi-year option on the table. If the only choices are "accept the increase" or "leave," you have removed the one path where both parties gain. The rate lock in exchange for term is the offer that most often turns a defensive renewal into a longer contract.

Discovering the billing constraint after announcing. Promising graduated pricing that your platform cannot schedule means someone manually re-rates hundreds of accounts twelve months later, and they will miss some. Validate the configuration in a sandbox before the announcement, not after.

Verbal exceptions. A CSM agrees to an extra year on a call, notes it in the CRM, and leaves the company. The customer remembers it; you have no document; the auditor has no basis for the rate. Every exception becomes a countersigned amendment or it did not happen.

Ignoring the contract audit. Raising the price on an account whose MSA locks the rate is a breach, and it will be found. It also destroys credibility on every other account that hears about it. The audit is unglamorous and it is the first task, not the last.

Letting the policy skip RevOps. Pricing owns the number, CS owns the relationship, Finance owns the model — but the account tagging, the price book, the expiry alerts, the quota adjustment, the dashboard, and the CPQ guardrails all land on RevOps. If RevOps is briefed after the announcement, the policy exists as a slide and not as a system, which is precisely how you end up handling grandfathering by spreadsheet in 2029.

Related questions

Do we have to grandfather multi-year contracts?

You are not grandfathering them — you are honoring them. A locked multi-year rate stands until expiry regardless of policy. The grandfathering decision only applies at that contract's renewal, when you choose whether to step them to current pricing immediately or over a cycle.

Should the new price show on the public pricing page immediately?

Announce to existing customers first, then update the public page after the notice window opens. Customers who learn about their own increase from your website treat it as a disclosure failure, which is a harder problem than the price itself.

How do we handle accounts mid-implementation?

Hold them at contracted pricing through go-live plus one full renewal cycle. Raising the price on a customer who has not yet realized value is the highest-churn-risk move available, and the revenue involved is usually small relative to the reference-ability at stake.

What about customers already asking for a discount?

Treat the grandfather window as the concession. An at-risk account that wants both a discount and a rate hold should be offered the multi-year structure — certainty in exchange for term — rather than a stacked concession that resets their price expectations permanently.

Does grandfathering complicate revenue recognition?

It creates parallel price schedules for the same SKU, so the standalone selling price analysis and any allocation across performance obligations need to reflect that. It is manageable, but loop finance in during design rather than at close.

FAQ

What exactly is grandfathering when changing prices?

Grandfathering lets existing customers keep their current rate for a defined period after you raise prices for new customers — most commonly 12 to 24 months, or until their next renewal. It is a retention mechanism that trades near-term realized revenue for continuity in the installed base and a smoother path to the new price.

Who should own the policy?

Finance owns the economics and the model, Customer Success owns the relationship risk, and RevOps owns the implementation — segmentation, price books, CPQ guardrails, expiry alerts, and reporting. Sign-off sits with the CRO and CFO. In practice the policy fails when RevOps is told about it rather than involved in designing it.

How long should the window be?

Align it to renewal cycles rather than to a round number. Twelve months is standard for annual contracts; 24 to 36 months shows up where multi-year terms or extended commitments are involved. What matters more than the length is that the end date is explicit, stored in a system, and communicated to the customer at the start.

Is it ever right to skip grandfathering entirely?

Yes — for high-volume, low-ACV, transactional segments where maintaining parallel price books costs more than the churn it prevents. Pair it with a one-time credit or a service concession so the first invoice under new pricing is not a surprise, and keep the notice period intact.

What happens when the window expires?

The account steps to current pricing at its next renewal, and this should be a scheduled system event, not a discovery. Notify roughly 90 days before expiry with the same discipline used for the original announcement. Track the conversion rate at expiry as a distinct metric — it tells you whether the policy actually worked or merely deferred the churn.

How do we keep the exceptions from becoming the policy?

Write down the CSM's standing authority — how much extension they can grant unilaterally — and require anything beyond it to go to VP CS or RevOps, documented as a contract amendment. Review all live exceptions annually. Undocumented verbal extensions are how a two-year program becomes permanent.

Sources

• https://openviewpartners.com/blog/pricing-strategy/
• https://www.priceintelligently.com/blog
• https://www.chargebee.com/blog/saas-pricing-models/
• https://stripe.com/docs/billing/subscriptions/migrate-prices
• https://www.recurly.com/blog/
• https://oag.ca.gov/consumers/general/automatic-renewals
• https://www.ftc.gov/business-guidance/resources/negative-option-rule
• https://www.gartner.com/en/sales/topics/pricing-strategy
• https://hbr.org/2016/03/a-quick-guide-to-value-based-pricing
• https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-pricing-power-imperative

Related on PULSE

• [How do you raise prices without churn in 2027?](/knowledge/q12396)
• [How do you set B2B SaaS pricing — and raise prices without losing customers?](/knowledge/q10880)
• [How Do I Raise Contribution Margin Without Raising My Prices?](/knowledge/q16125)
• [How do you handle grandfathering rules when legacy reps depart?](/knowledge/q746)
• [How are 2027's AI procurement tools changing the way vendors structure their pricing proposals?](/knowledge/q16558)