The easiest payment migration in the industry is also the most underestimated: moving between two Stripe accounts. Easiest, because Stripe copies customers and payment methods across accounts for you — no PCI export, no provider handshake. Underestimated, because everything else is your job: new object IDs everywhere, subscriptions rebuilt from scratch, and integrations that quietly assume the old account in a hundred places. I have led migrations moving $100M+ in recurring revenue; this guide covers the account-to-account variant.
What Stripe moves, and what you move
- Stripe moves: customers and payment methods. Requested through Stripe, executed inside Stripe's PCI scope, delivered with an old-ID-to-new-ID mapping file. Cards, most saved payment methods, and customer records arrive intact.
- You move: everything with business meaning. Products, prices, coupons, promotion codes, tax settings, webhooks, Connect topology, and — the heart of it — live subscriptions, which you recreate in the destination account scheduled to take over at each renewal boundary, exactly like a cross-provider migration.
- Nobody moves: history and reputation. Charge history, dispute records, Radar's learned fraud patterns, and issuer familiarity stay behind. Expect a Radar settling-in period on the new account, and archive the old account's reporting for finance before it goes quiet.
The ID remapping is the real project
Every copied object gets a new ID, and your systems are full of the old ones: database columns, queued jobs, analytics events, support tooling, spreadsheet exports, hardcoded price IDs in config. The migration is only as done as your grep is thorough. Three rules from the field:
- Build the remap as a first-class table, not a script variable: old ID, new ID, object type, migrated-at. Every downstream fix reads from it, and reconciliation depends on it.
- Webhooks cut over per event type, not all at once. Run both endpoints during the transition window with idempotent handlers, and route by account so replayed events cannot double-process.
- Metadata is your continuity thread. Stamp every recreated object with the old account's IDs before the first wave — cross-account reconciliation is only queryable if the link exists on the objects themselves.
You do not need to become an expert in any of this. Everything on this page is my day job: I run fixed-scope migrations off your old Stripe account end to end — eligibility analysis, the credential transfer, cutover sequencing, reconciliation — while your team keeps shipping product. If you want your plan pressure-tested first, that is a 90-minute clarity call. If you want it done, start with the migration service.
The framework every migration shares
Whatever provider you are leaving, the platform you build is the same five layers: a snapshot mirror so selection never touches production; a selector that is the single source of truth for eligibility; batching with a migration lock and one correlation ID stamped everywhere; the credential transfer covered above; and cutover pinned to each subscription's renewal boundary— the old provider bills the last cycle it owns, Stripe bills the next one, and no customer is ever billed twice or skipped. Reconciliation runs the whole time, counting row states rather than log events, with Stripe's warehouse as the authority for "ever migrated."
I wrote the full treatment — sequencing, reconciliation formulas, the long-tail playbook, and ten field lessons — in the complete migration guide. This page covers what is different about your starting point.
Frequently asked questions
Can Stripe copy payment methods between two Stripe accounts?
Yes — Stripe supports copying customers and their saved payment methods from one Stripe account to another on request, inside Stripe's own PCI scope, so no external export is involved. It is the easiest credential transfer in the industry. Everything else — subscriptions, products, prices, coupons, webhooks, Radar history — does not copy and is rebuilt by you.
Do object IDs stay the same across Stripe accounts?
No. Copied customers and payment methods get new IDs in the destination account, and Stripe provides a mapping between old and new. Every place your database, jobs, and analytics store a cus_, pm_, sub_, or price_ ID needs remapping — finding all of those places is usually the largest single task in the project.
Why would anyone migrate between Stripe accounts?
Entity restructuring (new legal entity or country of settlement), mergers and acquisitions, consolidating accounts that grew organically, separating business lines, or unwinding an account structure that no longer matches how the company operates. The trigger is almost always legal or financial, and the work is almost entirely on your side, not Stripe's.
Written by Andrej Dragojevic, Stripe Certified Professional Billing Architect.