How to Migrate Stripe Subscriptions to Another Account

Stripe cannot move subscriptions between accounts. Its customer copy moves customers and saved payment methods, but subscriptions, products, prices, and schedules stay behind. To migrate Stripe subscriptions to another account, you recreate them as subscription schedules in the destination account, each starting on the original renewal date, then cancel the source subscriptions at period end.

This applies whether you sold a SaaS, set up a new legal entity, or are moving to a new country. If you can transfer the whole Stripe account instead (only possible within the same legal entity), that is simpler. If you are buying the business, share this runbook with the seller.

What Stripe's customer copy does

In the Stripe Dashboard, Copy to account copies customers between accounts.

It copies:

• Customer records (cus_...). Customer IDs stay the same after the copy.
• Saved payment methods attached to those customers. Payment method IDs change.

It does not copy:

• Products (prod_...) and prices (price_...)
• Billing meters
• Active subscriptions (sub_...)
• Subscription schedules

The destination owner must accept the copy in their Dashboard before it starts. After the copy, the destination account has customers and cards, and zero subscriptions. The source account keeps billing. You must recreate the subscriptions in the destination account and end them in the source account at the right moment.

Before you start

Run through this list before you touch either Stripe account:

• You have admin access to both the source and destination Stripe accounts.
• You have exported all active subscriptions and their renewal dates from the source account.
• The person in each account who will accept or initiate the customer copy is identified and available.
• You know when to switch your application's API keys and webhooks to the destination account.
• Allow time for the copy. Stripe's guidance: most copies finish within 72 hours.
• If possible, run the full steps in a sandbox first. Stripe recommends a test migration before the live run.

The two failures to prevent

Two mistakes cause real harm during a subscription migration. Both are covered in detail at preventing double billing during a Stripe account transfer.

1. Double charge. You create active subscriptions in the destination account while the source subscriptions still run. Both accounts bill the same period.
2. Early cancellation. You cancel the source subscriptions before the destination schedules are verified. A customer loses paid access if the destination fails to collect.

Order and verification prevent both.

Step 1: Create restricted keys

Never migrate with a secret key. Create restricted keys with the smallest permissions for each stage:

1. Read-only key on the source account, for the scan and the plan.
2. Write key on the destination account, for products, prices, meters, customers, subscriptions, and invoices, with read access on payment methods.
3. Cancellation key on the source account, which can only set subscriptions to cancel at period end. Create it last, after verification.

Step 2: Scan the source account and recreate the catalog

With the read-only key, list every active subscription and the products, prices, and billing meters it uses. Note each price's currency, amount, and billing interval.

In the destination account, recreate the same products and prices. For usage-based billing, recreate each billing meter with the same event name and aggregation. Keep the source ID in each new object's metadata, so the two catalogs map to each other.

Step 3: Decide the flagged subscriptions

Not every subscription can move in a batch. Flag these and decide each one: move now, or leave for now.

• Renews within 48 hours. There is no time to copy the customer, verify the destination, and switch your application. Leave it. Move it after it renews in the source account.
• No saved payment method. The first renewal in the destination account would fail.
• Coupon or discount. Schedules are created at the list price. The coupon does not carry over.
• Trial, past due, or already set to cancel. There is no settled renewal to schedule from.
• Two customer records with the same email. Matching by email cannot tell them apart. Move one at a time.
• Existing schedule, manual tax rates, invoice billing, unusual items. Rebuild these by hand.

Step 4: Copy the customers with Stripe

Build the customer list from the decisions. In the source account's Dashboard, open Customers, choose Copy to account, upload the list, and enter the destination account ID. The destination owner accepts the request. Stripe copies the customers and their payment methods.

Then verify the copy in the destination account. Find every customer, map it to its source customer, and check the default payment method. The copy sometimes drops the invoice default payment method. Set it from the copied payment method before you create any schedule.

Step 5: Create one subscription schedule per subscription

Never create an immediate subscription in the destination account. Create a subscription schedule instead:

1. Read the source subscription's current_period_end.
2. Create a destination schedule that starts on that exact timestamp.
3. Attach the copied customer and the recreated price, with the same quantity.

The destination account then bills only when the paid period in the source account ends. The customer is charged once, on the expected date.

You can also use Stripe's Billing migration toolkit to create these schedules from a CSV instead of the API. The toolkit requires destination account IDs (not source IDs) in every column, needs a start date at least 24 hours in the future, and does not cancel the old subscriptions for you.

Step 6: Verify every schedule

A successful API response does not prove the result. Read each schedule back and check:

• The destination customer ID
• The start date against the source current_period_end
• The price, currency, and quantity
• The tax settings

Fix any mismatch before you touch the source account.

Step 7: Cancel the source subscriptions at period end

With the cancellation key, set each moved source subscription to cancel_at_period_end: true. Never cancel immediately. The current period finishes as paid, and the destination schedule starts at the same moment.

Step 8: Keep the migration records

Record the source subscription IDs, the copied customer IDs, the schedule IDs, the verified renewal dates, and the decision on every flagged subscription. Both owners keep the same records.

After the cutover: the first renewals

Watch the first renewal cohort in the destination account for failed payments. Check that no source subscription is still active without cancel_at_period_end set. Keep both Stripe accounts open until the last source billing period has ended.

What stays your job

This runbook covers Stripe Billing objects only. Your team still updates the application database with the new customer and subscription IDs, switches the API keys in your deployments, points the webhooks at the destination account, and checks entitlements.

Doing it with SubPorter

SubPorter runs these eight steps as a migration project. The source account stays read-only until every schedule is verified. Three separate restricted keys keep each stage isolated. Subscriptions renewing within 48 hours are flagged. The cancel step runs only after verification.

Pricing is a one-time fee per project: $99 for up to 100 subscriptions, $199 above 100. Flat, not based on MRR.

Scan your source account for free to see what needs to move, or view pricing.