You migrate existing customers to usage-based pricing by mapping each account's current bill to a usage equivalent, running a shadow-billing period against real usage data, and moving cohorts over with a grandfathering window. This guide covers the bill-mapping math, three migration paths, and the communication sequence that keeps churn down.
Why do teams migrate to usage-based pricing?
Teams migrate to usage-based pricing because flat-rate plans and variable per-interaction costs invert margins: the heaviest users pay the same as the lightest and cost far more to serve. For AI products the inversion is structural. Model inference consumes roughly 23% of revenue at scaling-stage AI companies (ICONIQ State of AI, January 2026), and that cost scales with usage while a flat subscription doesn't.
The market is already moving. The share of B2B software companies on pure flat-fee subscriptions fell from 29% to 22% in a single year, while hybrid pricing grew from 27% to 41% (The state of B2B monetization in 2025, Growth Unhinged, June 2025).
The hard part isn't deciding to switch. It's moving a live customer base without churning the accounts you want to keep. Done well, the migration is mostly preparation: per-customer usage data, a billing platform for AI products that can represent both the old and the new model during the transition, and a communication sequence measured in weeks, not days.
Map every customer's current bill to a usage equivalent
Before you announce anything, compute what every account would have paid under the candidate usage price. This backtesting step is what separates a controlled migration from a repriced surprise, and it needs 6 to 12 months of historical usage per account to be meaningful.
The sequence:
- Pick the value metric. The unit your pricing meters: tokens, requests, generated outputs, agent runs, GPU seconds. It should track your cost and be legible to the customer. (For a refresher on the underlying model, see what usage-based billing is.)
- Backtest against real usage. For each account, multiply historical usage by the candidate rate and compare the result to the current subscription bill.
- Tune the rate to the distribution. A commercially safe starting point is a rate where most accounts land within roughly 10 to 15% of their current bill. You're not trying to change anyone's price on day one; you're trying to change the model.
- Flag the outliers. Accounts whose usage-equivalent bill is far above their current bill are your unprofitable accounts today. They are also your churn risks tomorrow, so they get caps, a grandfather plan, or a direct conversation rather than a surprise.
This is standard practice for a reason: as of January 2025, 85% of SaaS companies already use some form of usage-based pricing (2025 State of Usage-Based Pricing, Metronome and Greyhound). Customers accept the model when it maps to value; Bain found 80% of customers reported better value alignment under consumption pricing (Bain, 2022).
Grandfather, opt-in, or forced switch: which migration path fits?
There are three ways to move existing customers, and the choice is a risk-segmentation decision, not a philosophical one. High-value and enterprise accounts usually get grandfathered or opted in; monthly self-serve accounts can absorb a forced switch if the notice period is real.
| Path | How it works | Margin repair | Churn risk | Watch for |
|---|---|---|---|---|
| Grandfather | Existing accounts keep legacy pricing indefinitely or until renewal; new accounts start on usage pricing | Slowest. Unprofitable accounts stay unprofitable until they roll off | Lowest | A legacy base that never shrinks; two price books to support |
| Opt-in with incentive | Existing accounts are offered the new model with bonus credits, a price lock, or a better unit rate | Moderate. The accounts that gain from switching move first | Low | Adverse selection: the accounts that cost you most stay put |
| Forced switch | Every account moves on a stated date after a notice window | Fastest | Highest | One surprise invoice undoes the entire rollout |
The 2025 to 2026 AI tooling market supplied both poles. Cursor moved its Pro plan from 500 fast requests to a $20 usage pool at API rates on June 16, 2025, effective the same day for existing subscribers (Cursor, July 2025). The team spent the next three weeks managing the backlash. GitHub announced Copilot's move to usage-based billing on April 27, 2026, 35 days before the June 1 effective date (GitHub, April 2026). It grandfathered annual subscribers until their plans expired and gave Business customers promotional credits through August 2026. Same switch to usage-based pricing; opposite customer experience.
The destination doesn't have to be pure usage pricing. Hybrid plans, a subscription with an included allowance and usage overage, absorbed most of the flat-fee exits in 2025; see hybrid pricing for AI products for when that model fits.
Run a shadow-billing period before the cutover
Run the new pricing in parallel for one to two billing cycles before any customer is charged under it. Shadow billing means computing what each invoice would have been at the new rates without issuing it, and it's the last checkpoint where a pricing mistake costs you nothing.
- Instrument usage events per customer, if you haven't already. Without per-account usage capture there is nothing to shadow.
- Compute shadow invoices at the candidate rates every cycle.
- Compare each shadow invoice to the account's actual bill and re-check the distribution from your backtest. Real behavior drifts from historical behavior.
- Share the projected numbers with affected customers before the cutover, not after. GitHub shipped a preview billing experience in early May 2026 so Copilot users could see projected costs a month before the switch (GitHub, April 2026); the same idea works at any scale.
- Set the cutover date, and decide the rule for cycles already in flight.
Shadow billing is practitioner practice rather than a documented standard, but the two most visible migrations of the period argue for it from both directions: Cursor cut over without a preview period and apologized; GitHub previewed and didn't have to.
How do you communicate the switch without burning trust?
Announce early, show each customer their own projected bill, and give a real window. Customers accept a usage-based pricing rollout when they can predict their own number; they churn when the first surprise arrives as an invoice.
A sequence that works: announcement with the reason for the change, per-account impact preview, a reminder before cutover, the cutover itself, and a check-in on the first real invoice. Every step should show the customer their own data, not a generic pricing page.
Cursor's June 2025 change is the cautionary case. Users burned through the new $20 allotment in hours on frontier models, and TechCrunch attributed the change to Cursor absorbing the cost of longer-horizon agentic tasks (TechCrunch, July 2025). CEO Michael Truell posted an apology on July 4: "Our communication was not clear enough and came as a surprise to many of you" (Cursor, July 2025). The company refunded surprise charges incurred over the 19 days between the change and the apology. The pricing logic was defensible; the rollout was not.
Repair gestures help when prevention fails. Replit issued $10 goodwill credits to affected members after its 2025 effort-based pricing rollout drew similar complaints (Replit effort-based pricing recap, July 2025). And the pattern isn't limited to AI coding tools; Clay's pricing change shows the same mechanics applied to a GTM platform's credit model.
Common pitfalls when you migrate to usage-based pricing
Most failed migrations break on data, infrastructure, or accounting rather than on the price itself.
No raw usage history. If your current stack stores pre-aggregated counters instead of raw events, you can't backtest; there's no way to recompute what an account would have paid at a different rate. Teams on flat-rate subscription stacks often have to build usage capture first and delay the migration by a quarter.
The billing system can't represent the new model. Usage-based billing platforms split into two architectures. Invoice-based platforms such as Orb and Lago meter events through the period and reconcile them into an invoice at cycle end. Real-time platforms such as Credyt and Stigg price and debit the customer's balance as usage happens, and Stripe Billing is subscription-first with metered add-ons. Neither architecture is legacy. Pick for your workload, and expect to change prices again: PricingSaaS counted 1,800+ pricing changes across the top 500 transparent SaaS and AI vendors in 2025 (2025 state of SaaS pricing changes, Growth Unhinged and PricingSaaS, December 2025), so the system you migrate onto must make the next change cheap.
Bill shock at the first usage invoice. The single biggest churn driver in a migration. The prevention pattern is standard across large consumption platforms: notification thresholds below the cap, a soft stop at the cap, and live balance visibility for the customer; Snowflake's resource monitors notify at configurable thresholds and suspend at the limit. If your stack can't enforce spend expectations programmatically, communication alone won't save the rollout.
Revenue recognition changes. A hybrid destination splits recognition: the platform fee is recognized ratably while the usage component is recognized as consumed. Finance needs to see this coming before the first mixed invoice, not after; see revenue recognition for usage-based billing for how credits complicate the picture.
Next steps
Now that you've read our guide on how to migrate existing customers to usage-based pricing, you're probably wondering how to get started.
A reliable migration to usage-based pricing runs on infrastructure that captures usage per customer, changes pricing rules without an engineering cycle, and shows every customer their own balance before the invoice does.
That's Credyt.
Credyt is real-time monetization infrastructure for AI. Here's how Credyt handles a migration:
- Billing model versioning: change pricing rules in the dashboard without touching code; new events price on the new rules immediately.
- Hybrid billing: subscription plus an included credit allowance plus usage overage, the most common migration landing zone.
- Real-time usage billing: meter any event and debit the customer's balance the moment it occurs.
- Branded billing portal: customers see their live balance and usage history, so the first usage invoice is never a surprise.
- Profitability analytics: see which migrated accounts are margin-positive in real time.
Learn how Credyt can help you migrate to usage-based pricing without stitching infrastructure together.
Related resources
- How AI companies adopt real-time billing without replacing their stack. The adoption path when you keep your PSP and finance systems.
- How to implement consumption-based pricing. The design step that precedes migration: metrics, rates, and packaging.