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

When you sell a SaaS business or move billing to a new corporate entity, you must migrate Stripe subscriptions to another account. Many founders expect Stripe to provide an automated dashboard button to move complete billing configurations between accounts. It does not.

To migrate Stripe subscriptions to another account safely, you must understand what Stripe copies, what it leaves behind, and how to sequence each API operation. A rushed cutover risks charging customers twice or cancelling paid access prematurely.

This guide details the technical steps to migrate active Stripe subscriptions safely without double billing or lost renewal dates.

What Stripe Customer Data Copy Does and Does Not Do

The starting point for an account migration is Stripe Customer Data Copy. Initiated through the Stripe Dashboard, this process moves specific customer records between accounts.

Stripe Customer Data Copy moves:

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

It does not move:

• Products
• Prices
• Billing meters
• Active subscriptions
• Subscription schedules

After Customer Data Copy completes, the destination account contains customer records and payment tokens, but zero active subscriptions. The source account continues billing existing subscriptions. You must recreate active billing in the destination account and retire source subscriptions at the proper time.

The Core Risk: Double Billing and Early Cancellation

Moving live subscriptions carries clear risks. The subscribers being moved represent the business revenue you just handed to an acquirer. Mistakes harm customer trust immediately.

Two primary failures occur during unverified migrations:

1. Double charging: Creating active subscriptions in the destination account while source subscriptions remain active causes both accounts to bill during the same cycle.
2. Premature cancellation: Cancelling source subscriptions before destination schedules are verified causes customers to lose paid access if payment collection fails.

Preventing both failures requires strict sequencing and verification.

Step 1: Recreate Catalog Objects and Meters

Before migrating subscriptions, you must recreate your billing catalog in the destination account.

Every active subscription relies on underlying catalog objects:

• Products (prod_...)
• Prices (price_...)
• Billing meters for usage-based billing

Using a read-only restricted API key on the source account, catalog every active product, price, currency, and billing interval. In the destination account, recreate identical products and prices.

If your SaaS uses metered billing, recreate billing meters in the destination account with identical event names and aggregation rules. This ensures post-cutover usage events map correctly.

Step 2: Establish Safety Gates and Restricted Keys

Never use root secret keys for migration workflows. Use restricted keys with minimal required permissions.

A safe migration architecture follows three gates:

1. Read-only staging: The source account owner connects a restricted key limited strictly to read permissions. Catalog review and planning happen without modifying the source account.
2. Destination write key: The destination account owner provides a restricted key permitted only to create catalog objects and subscription schedules.
3. Narrow cancellation key: Cancellation uses a final restricted source key uploaded only after destination verification passes.

Step 3: Run Customer Data Copy and Verify Defaults

The seller initiates Customer Data Copy in the Stripe Dashboard, targeting the destination account. The buyer then accepts the incoming transfer in their Stripe Dashboard.

Once the transfer finishes, verify the copied customer records in the destination account before writing subscriptions.

Stripe copies payment methods, but sometimes drops the customer's invoice default payment pointer. SubPorter verifies each copied customer and sets the invoice default payment method where the copy dropped it. Without an invoice default payment method, destination subscription schedules cannot collect payments automatically.

Step 4: Handle Near-Renewal Subscriptions and Manual Review

Not every subscription should be migrated in an automated batch. Certain subscriptions require human judgment.

SubPorter flags conditions that need manual review, including:

• Near-renewal buffer: Subscriptions renewing within a 48-hour buffer are held rather than moved immediately. Migrating a subscription hours before renewal risks racing Stripe billing webhooks. Holding these subscriptions allows them to renew in the source account before moving.
• Automatic tax configurations: Subscriptions with automatic tax enabled require manual verification to confirm that destination tax registrations and settings match the source.
• Other verified review triggers: Discounts or coupons, past-due or trialing status, existing subscription schedules, manual tax rates, missing default payment methods, and unusual item shapes are also held for a person to review.

Both parties review and resolve flagged rows before proceeding to live writes.

Step 5: Anchor Destination Subscription Schedules

To prevent double billing, never create immediate subscriptions in the destination account. Instead, create Stripe subscription schedules.

A subscription schedule allows you to specify a future start date. For each active subscription:

1. Identify the source subscription's current period end date.
2. Create a destination subscription schedule set to begin on that exact current period end timestamp.
3. Associate the copied customer and recreated destination price.

Anchoring destination schedules to existing renewal dates ensures the buyer bills only after the seller's paid period expires. Customers experience continuous access with zero double charges and zero free days.

Step 6: Verify Destination Schedules and Retire the Source

Before modifying the source account, you must verify destination writes. API success responses only confirm that a request was received.

Retrieve each created destination schedule and confirm:

• Correct destination customer ID
• Accurate scheduled start date matching source renewal
• Correct price ID, currency, and quantity
• Proper automatic tax configuration

Only after all destination schedules pass verification, and both parties sign off, do you retire source subscriptions.

Update source subscriptions to cancel_at_period_end: true. Never cancel source subscriptions immediately. Setting them to cancel at period end allows active paid periods to conclude naturally while destination schedules activate on renewal.

Step 7: Export Audit Packet and Maintain Scope Boundaries

Conclude the migration by generating an audit packet for the closing binder.

The audit packet records:

• Source subscription IDs
• Copied destination customer IDs
• Destination schedule IDs
• Verified renewal dates
• Decisions on subscriptions held for manual review

Scope Honesty

SubPorter handles Stripe Billing objects: products, prices, billing meters, customer verification, payment defaults, destination schedules, and period-end cancellations.

The buyer's engineering team remains responsible for:

• Updating application database customer and subscription records
• Updating Stripe API keys in application environments
• Configuring destination webhook endpoints
• Verifying application user entitlements

Maintaining this clear boundary keeps billing verification manageable and transparent.