How to Migrate Stripe Subscriptions to Another Account: The Step-by-Step Runbook

When you sell a SaaS, or move billing to a new legal entity, you must migrate Stripe subscriptions to another account. Stripe has no button for this. Its customer copy moves customers and saved payment methods. It does not move subscriptions, products, prices, billing meters, or schedules.

This guide gives the safe order of steps. Follow it, and no customer is charged twice and no renewal is lost.

What Stripe's customer copy does

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

It copies:

• Customer records (cus_...)
• Saved payment methods attached to those customers

It does not copy:

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

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.

The two failures to prevent

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, and subscription schedules.
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.
• 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.

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.

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.

SubPorter runs these eight steps as a migration project, with the source account read-only until every schedule is verified.