Pricing Migration Without the Churn Spike 2026

Before wave one, finance and the CS lead agree the pause rule in writing. Count each account once, and compare each wave with similar accounts (same segment and size band) at the same point in their renewal cycle over the last year. Default: the migration pauses and the notice is rebuilt if the share of a wave's accounts that cancel, give notice or ask to downgrade within 30 days of the notice is more than twice that baseline. Set an account-count limit and an ARR-at-risk limit too; crossing either also pauses. Annual customers can't cancel mid-term, so count non-renewal notices and replies that say they'll leave. Review every account that responds badly, and don't read missing baseline data as a sign the wave is safe.

Then build the benchmark: for each new plan, the customers whose usage maps to it and who renewed at the same or higher revenue after 12+ months. Aim for 20 per plan; with fewer, label it low confidence. This compares past usage mapped to the new plans; it doesn't yet show who will renew at the new prices. Record their median usage on the measures the new plans are priced on (seats, volume, features). Default: "at the benchmark" means at least 80% of that median. Your CS lead approves it.

For every account, pull usage against the new plan limits, old and new price per year, and overages or workarounds (sources in the kit below). Under about a hundred accounts, do it by hand in a spreadsheet.

Map each account to the new plan its usage fits and compare it with that plan's benchmark. Then check the records:

• Price lock? Contract terms in the CRM or billing.
• Renewal date: from the CRM.
• Usage trend: active users over 90 days. A gap in the events is a data problem, not a signal; fix the mapping first.
• Custom terms: discounts or add-ons. Use the real price, after discounts, in the price change.

Leave it alone if it has a price lock, renews inside a default 90 days, or its usage records have gaps (fix them and recheck before the next wave). Everything else gets a track.

Set Recommended move to No move, note the reason, and set Review date to the lock's end or 90 days before renewal. The new price goes into the renewal brief for the renewal check. Why no move is a move: leave it alone.

Apply these in order; the thresholds are defaults to tune:

1. Call first: the account is in your top 10% by ARR, or its price rises more than 10% and usage is below the benchmark or down 20% in 90 days.
2. Upgrade win: the new plan is better for how they already work – it absorbs overages they pay, or includes features they work around.
3. Migrate now: everything else.

Say an account pays $9,600 a year, would pay $11,400, and runs 6 active users where similar customers on that plan run 14. That's call first. The $1,800 is a comparison, not a forecast. (The numbers are illustrative.)

Your team chose to automate this move: Customer.io sends the notice below in waves, smallest and steadiest accounts first, each send logged on the HubSpot record. Wave size is your call on exposure: smaller waves reduce what's at risk at once but take longer. Before wave one, confirm you can apply the new price. Default to at least 60 days' notice before the new price applies, and meet any longer period or other requirement in the contract and applicable law. Keep the notice factual and separate from promotional offers, and send it as a service notice, not marketing.

A task for the account owner with the upgrade note below. When their yearly spend would change by more than a default $5,000 either way, the AM makes it a call. If the notes prove right in the early waves, your team may choose to automate this lane too.

No call-first account hears about the change from an email. The brief below carries a bridge offer: current price held for a default 6 months (12 for your top 10% by ARR), in writing, with an end date – paired with a plan to get them using what they pay for. Finance approves the bridge terms before wave one.

The AM or CSM runs the move as drafted, changes it, or passes. They own every customer conversation. Before acting, record the success measure and review date, and set Bridge end date for any bridge.

Thirty days after each wave, the CS lead and finance read cancellations, downgrades and replies by track against the pause rule, and write the wave read below. Over the line, pause: find the track and message behind it, rebuild, then resume. The next wave waits for the read.

Eight weeks after each wave's new price applies, review that wave's billing and early responses, and track renewals as they come due. Once the last wave has had its eight weeks, set Review result on each account and answer: churn per wave against the pause rule, NRR through the window (with the price increase reported apart from expansion, contraction and cancellation), upgrade wins booked, and whether bridge accounts are closing the gap to the benchmark. Keep activity (notices sent), progress (accounts migrated and using the plan) and results (renewals, upgrades) apart, and note what else played a part. Where a track didn't hold, change the move, stop it, or give it time. To compare earlier and later optional announcements and guidance, use what changed after the release. That comparison doesn't measure the effect of the price change itself. Then update the benchmark to the new plans.