Stripe price migrations for the sites you manage
You run subscriptions for other people's businesses. When a client raises prices, their platform changes what new members pay, but not what existing members pay. That is the job this does, one client account at a time, without cancelling and recreating anybody.
The preview is free on any account, live or test. Nothing changes until you say so. Jump to pricing if that's what you came for.
Works with Paid Memberships Pro, MemberPress, Ghost, Substack, Beehiiv, Thinkific and plain Stripe. Anything that created native Stripe Billing subscriptions.
The job nobody has a good answer for
Every membership platform can change what new members pay. Almost none can change what existing members pay.
So the options a client is normally offered are cancel and resubscribe everybody, which loses a chunk of them and resets every renewal date, or pay someone to write a script against the Stripe API. Neither is a good thing to propose to a client who just wants to charge $12 instead of $10.
PricePilot re-prices existing subscriptions in place, in the client's own Stripe account, keeping each member's renewal date, trial and discount intact.
What a client run actually looks like
Five steps, and three of them are things you can show the client.
- Get a restricted keyWrite on Subscriptions, Prices and Products, read on Customers, Account and Invoices. Nothing else, and nothing that can create or edit an invoice. If you're only moving members between prices that already exist, Products can be Read. Your client can create it themselves and hand you only that. There's a ready-made request email further down.
- Preview, then get sign-offThe preview lists every affected member and the MRR change, and exports a CSV. That CSV is what you send the client. Nobody has to approve a migration they cannot see.
- Set a notice windowOn a scheduled run, anyone renewing inside the window is held to their following renewal. Trialing members are the exception: they aren't pushed, so their new price starts when the trial ends. Exclude them if that's sooner than you want.
- Run itThe CSV now carries each member's real change date rather than just their next renewal, which is what the client's email platform needs to schedule notices.
- Reverse if you need to, then revoke the keyOne click releases anything still pending. Keep the tab open until the client has signed off, because reverse belongs to the run you just did. Delete the key in Stripe when the job is done.
Rehearse for free
Test mode is free end to end. Run the whole migration and the reverse on test data before anything touches a real member.
Platform-agnostic
PMPro, MemberPress, Ghost, Substack, Beehiiv, Thinkific or plain Stripe. If it created native Stripe Billing subscriptions, it can be re-priced.
What you actually put in front of the client
Two artifacts do the persuading, and you get both before committing to anything.
The first is the forecast. Connect a key, pick the price you're moving off and the price you're moving to, and you get the number the client cares about before a single subscription changes. The affected-member list is free and immediate; the MRR figures ask for an email once, and then it remembers you:
Illustrative figures. Your preview shows the real ones for the account you connect.
That is the slide. A client who has been putting off a price rise for two years is looking at $9,888 a year, next to a plan that says nobody gets charged without notice and it can be undone. This is the number most agencies cannot produce without a spreadsheet evening.
The second artifact is the CSV, and it does three jobs: it's the approval document before the run, the record afterwards, and the schedule your client's email platform needs. Every affected member, with the date their price actually changes:
| customer | renews_on | price_changes_on_est | pushed_for_notice | current_price | new_price |
|---|---|---|---|---|---|
| A. Whitfield | 2026-08-12 | 2026-08-12 | no | $10.00 | $12.00 |
| J. Okonkwo | 2026-08-03 | 2026-08-03 | no | $10.00 | $12.00 |
| R. Delgado | 2026-07-24 | 2026-08-23 | yes | $10.00 | $12.00 |
| S. Bergman | 2026-08-08 | 2026-08-08 | no | $10.00 | $12.00 |
| T. Nakamura | 2026-07-30 | 2026-07-30 | no | $10.00 | $12.00 |
A run on 15 July with a 14-day notice window, so renewals before 29 July fall inside it. R. Delgado was renewing on the 24th, so the change was pushed a cycle; everyone else changes on their own renewal date. Six of the eleven columns are shown, and the real export's price columns include the product name.
Notice the two date columns. renews_on is when they renew; price_changes_on_est is the estimated date their price changes, and for anyone pushed by the notice window those are different dates. That second column is what you schedule the client's notification emails against. For pushed rows it is accurate to within a day, and the exact date comes back in the export you download after the run.
And the run itself: in our testing a few hundred members completed in under five minutes. Worth knowing when you're deciding whether to quote this as a morning or an afternoon.
Pricing across client accounts
$399 a year per Stripe account, because a restricted key lives inside exactly one account.
If you manage several, one payment covers all of them. There isn't a fixed ladder, because what's fair depends on how many accounts you run and how often you re-price, and banded pricing tends to punish whoever sits just over a boundary. Tell us the shape of it and you'll get a number. The per-account rate is what's worth comparing against the hours a migration costs you by hand.
One client account
Several client accounts
Not sure which side of that line a client falls on? Send one of their subscription ids to hello@pricepilot.cloud and you'll get a straight answer on whether it can be re-priced. No charge, and no follow-up if the answer is no.
Get a bundle quote
Bundle pricing is worked out by whoever can actually answer, not routed through a sales team, and support lands in the same place. If a client migration looks wrong at 4pm, you're talking to someone who can read the code that ran it.
Connect a restricted key and the preview shows who's affected and what happens to MRR. Previewing changes nothing, and nothing is charged until you run a live migration.
Or write it yourself
For one client with fifty members, you probably should. It stops being an afternoon at the second client.
The happy path is one API call with a new price. The cost is in the states a member list accumulates over three years: trialing subscribers billed the moment you schedule a change, coupons that vanish when a schedule is rewritten, partial billing periods that make your reported dates a month wrong, and everything that only appears at scale. We wrote up the four that cost the most, with the mechanism behind each, because reading the Stripe documentation was not enough to catch any of them here.
The permissions to set
Six, and one of them is easy to miss.
Whether the key is one you create in an account you already administer, or one a client makes and sends over, these are the scopes a migration needs. Everything else stays None.
Miss Products and the tool cannot even list your prices, because expanding a product needs it even though the call is to the prices endpoint. If a client is creating the key for you, there is a copy-paste email with the reasoning behind each one.
What can go wrong, and when this isn't for you
Two things worth knowing before you put a client's billing through it.
First, how a run misbehaves when it does. Failures are per member rather than per run, so nothing is left half-applied without a record, and a scheduled change stays pending until each renewal, which is a window where undoing it costs nothing at all.
Failures are per member
One member failing doesn't abort the batch or leave it half-applied with no record. You get a per-member result and re-run only what didn't land.
Unsafe schedules are skipped
If a subscription already carries someone else's schedule, or has a discount that can't be carried across, it's skipped with a reason rather than pushed through. A reported skip you can act on beats a wrong invoice the client finds first.
There's a window to undo
Scheduled changes stay pending until each member's renewal, so until that date arrives reversing costs nothing. Once a member has renewed onto the new price, that invoice has happened and undoing it is a credit note, not a release.
Not native Stripe Billing
If the client's platform charges cards directly, or bills through Chargebee, Recurly or Paddle, there's nothing here to re-price. The test is whether subscription ids start with sub_.
One small client, once
For fifty members on a single account, use the free preview to see the scope, then decide honestly whether a year's licence beats doing it by hand.
Unusual subscription states
Three cases aren't handled yet and aren't flagged for you: subscriptions with more than one line item (the first line is the one re-priced), subscriptions already set to cancel at period end, and paused subscriptions. Exclude those manually, or send the account over and we'll check it for you.
Questions agencies actually ask
Does my client have to give me access to their Stripe Dashboard?
No. You connect with a restricted key, created in their account with only the access this needs: write on Subscriptions, Prices and Products, and read on Customers, Account and Invoices. Reading invoices is what powers the proration estimate; nothing in the key can create, edit or send one. No access to payment methods, coupons or tax rates. The key is never stored or logged, there is no database behind the tool, and either of you can revoke it in Stripe the moment the run is done. That is a much smaller thing for a client to hand over than standing Dashboard access.
Can I present this as my own service?
Yes. Nothing in the flow is client-facing. You connect, you run it, and what the client sees is the CSV and the outcome, both of which carry your name and not ours. There is no white-label programme to sign up to and no branding to strip, because there is no branded surface in front of your client in the first place. If you want to describe price migrations as a service you offer, that is the intended use.
I have twenty small clients, not four big ones. Does per-account pricing work for me?
Probably not at list price, and it is better to say so than to have you work it out after paying. Per-account pricing suits agencies running a handful of accounts with real subscriber counts. If you have a long tail of small clients, tell us the shape of it: how many accounts, roughly how many subscribers each, and how often you would actually re-price. Multi-account coverage already exists in the system, so it is a pricing conversation rather than a technical one.
Can I bill this to the client, or does it have to sit on my costs?
Either. Most agencies put the licence on their own account and bill the migration as a project, since it is easier to quote a piece of work than to explain a subscription to a client who thinks price changes should be free. If the client would rather own the licence, it is their Stripe account, so that works too and you just use their key.
Does this work for Paid Memberships Pro and MemberPress subscriptions?
Yes, and that is the main reason Migrate Pro exists. Those plugins can change what new members pay but not what existing members pay, so the usual options are cancel and resubscribe, which loses people, or a hand-written script. The determining factor is whether the platform created native Stripe Billing subscriptions (ids starting with sub_). If it did, they can be re-priced. That covers PMPro, MemberPress, Ghost, Substack, Beehiiv, Thinkific and plain Stripe.
Can I try it before asking a client to pay for it?
Yes. The preview is free on any account, live or test, and shows exactly who is affected and what happens to MRR before anything changes. Beyond that, test mode is free end to end in both products, so you can rehearse an entire migration and reverse on test data first. Nothing is charged until you run a live migration.
What do I hand the client when the migration is done?
The CSV, which lists every member, their old price, their new price and the exact date it takes effect for them. Before the run it is the approval document; after it is the record of what happened and the schedule their email platform needs. There is no reporting dashboard beyond that, deliberately, because what agencies actually need is a file they can attach to an email.
What if a run fails partway through?
Nothing is left half-applied without a record. Results are per subscription, so you can see exactly who landed and who did not, and re-run only the remainder without touching anyone twice. Rate limits are handled automatically with a countdown and the run continues. One thing to know: resume lives in the open tab, so if you close it you reconnect and work from the CSV rather than picking up mid-run. Download the CSV before you start a large migration.
What if the client changes their mind after we have run it?
There is a one-click reverse, and on a scheduled run it releases anything still pending, so those members are never invoiced at the new price. Two honest caveats. Reverse belongs to the run in your open tab, so keep it open until the client has signed off rather than closing it and coming back on Thursday. And any member whose renewal has already passed has been invoiced at the new price; putting that right is a credit note in Stripe, not a release. On an immediate run, reverse restores the original price going forward.
How do I give members proper notice when their renewals are scattered?
Set a minimum notice window in days. Anyone whose renewal falls inside it is held to their following renewal instead, so no member gets a price change with less warning than you promised. This was built for an agency whose client wanted 14 days' notice across monthly members renewing on every day of the month, where no single run date could satisfy everyone. The CSV then carries each member's actual change date, not just their next renewal, which is what an email platform needs to schedule the notices.
What happens to members who are on a trial or have a coupon?
On the scheduled option, trials are preserved: the trial runs to its original end date, nobody is billed mid-trial, and the new price applies at the first renewal after it ends. Discounts carry over with the same remaining term, so a coupon with two months left still has two months left. If a discount cannot be carried across for any reason, that member is skipped and reported rather than quietly moved to full price.
Do you work with Chargebee, Recurly, Paddle or direct card billing?
No. This is Stripe only, and specifically native Stripe Billing subscriptions. If your client's platform charges cards directly or bills through another provider, there is nothing here that applies. The quickest check is whether their subscription ids start with sub_ in the Stripe Dashboard.
Are there subscription states you don't handle?
Yes, three, and they are not flagged in the tool yet, so this is worth reading if you have inherited an account you did not set up. A subscription with more than one line item will have its first line re-priced, which may not be the line you meant. A subscription already set to cancel at period end is migrated like any other, which risks scheduling past a cancellation. A paused subscription is also treated normally. None of these are common on membership sites, but if your client's account has them, exclude those members by hand or send the account over and we'll check it before you run anything.
What happens to my clients if PricePilot disappears?
Nothing breaks, and that is a consequence of how this is built rather than a promise about the future. There is no database and nothing is stored on our side: every change is written into your client's own Stripe account. A price change that has been applied stays applied. A scheduled change is a native Stripe subscription schedule, so Stripe executes it on the renewal date whether or not this tool still exists, and you can see and cancel it in their Dashboard without us. Your client is never locked in, because nothing is holding their billing except Stripe itself. The only thing you would lose is the tooling for the next migration, and at that point you are back where you started, writing the script.
Do you touch payment methods or tax settings?
No. The restricted key you create has no access to either. It does read invoices, because that is how the proration estimate works out what a change would cost a member before you run it, but nothing in the key can create, edit or send one. PricePilot changes the price on a subscription and nothing else. You can see the full scope list on the tool itself before you connect.
Or send how many accounts you manage and you'll get a bundle number back.