Sandbox Seeding: Test Your Stripe Migration on a Realistic Copy of Your Live Accounts
Last updated:
The safest way to migrate Stripe subscriptions is to run the whole migration once before it counts. The problem: a test run is only as good as the data it runs against, and a freshly created Stripe sandbox is empty.
Sandbox Seeding fills your sandboxes with a realistic copy of your live accounts — products, prices, coupons, tax rates, and the subscriptions on your customers — so the test migration you run in MoveMRR behaves like the real one will.
Why an Empty Sandbox Tells You Nothing
A concern we hear in some form before almost every migration:
“Our live account is six years of pricing experiments — archived products, legacy prices, coupons on top of coupons. The buyer’s account already has its own customers and products. I want to watch this exact migration run before anything touches production. But my sandbox is empty.”
That concern is well founded. The things that make a migration hard are exactly the things an empty sandbox doesn’t have:
- A messy catalog. Archived products that still back live subscriptions. Prices created by an API version from years ago. Lookup keys, tiered pricing, multi-currency options.
- A destination that isn’t blank. Buyers usually have an existing Stripe account with its own customers and products. Collisions and mapping mistakes only show up when the destination has data.
- Real subscription shapes. Trials mid-flight, discounts, cancel-at-period-end flags, past-due invoices. A hand-made test subscription with one clean price exercises none of this.
Migrating two test subscriptions between two empty sandboxes proves the buttons work. It does not prove your migration will work.
What Sandbox Seeding Does
Sandbox Seeding is available on MoveMRR sandbox projects — projects connected with sandbox keys, built for testing. It has three parts:
- Seed the source sandbox. MoveMRR scans your live source account with a read-only live key and recreates its catalog and subscriptions in your source sandbox.
- Seed the destination sandbox. The same process against your live destination account, so the destination sandbox mirrors the buyer’s existing data.
- Customer sync. MoveMRR recreates the customers behind your source sandbox’s subscriptions in your destination sandbox — with Stripe test cards — and generates the customer mapping CSV automatically. This mirrors the Customer Data Copy step of a real migration, where Stripe copies customers and hands you a mapping file.
What Is and Isn’t Seeded
| Data | Seeded | Notes |
|---|---|---|
| Products & prices | Always | Product IDs and price lookup keys are preserved. Archived products are included — they may still back live subscriptions. |
| Coupons & promotion codes | Optional, on by default | Coupon IDs are preserved. Expired coupons and promotion codes are skipped with a note. |
| Tax rates | Optional, on by default | Recreated in the sandbox. Stripe assigns new IDs; MoveMRR maps old to new automatically. |
| Subscriptions | Optional, on by default | Active, trialing, and past-due subscriptions, recreated on the customers in your sandbox with billing dates preserved where possible. |
| Customers | Via Stripe / customer sync | Stripe’s own copy tool brings customers into your source sandbox. MoveMRR’s customer sync recreates them in the destination sandbox. |
| Payment methods | Replaced with test cards | Real card data never leaves Stripe. Sandbox customers without a payment method get a Stripe test card. |
| Webhook endpoints | Not seeded | If your test depends on webhooks, configure them in the sandbox manually. |
| Stripe Tax & payment settings | Not copied (intentional) | Fresh sandboxes have no tax or payment-method configuration, so copying these settings would make subscription creation fail. See the notes below. |
The Safety Model
Seeding reads a live account, so the safety rules are strict and simple:
- Read-only live key. You connect your live account with a restricted, read-only key (
rk_live_…). MoveMRR can generate a Stripe deep link that pre-selects only the read permissions it needs: customers, subscriptions, products, prices, coupons, and tax rates. - Used once, never stored. The live key is used once to scan your live account and never stored — not in the database, not in logs. It is held in memory only for the duration of the run. If you want to seed again later, you paste it again.
- Writes go to the sandbox only. MoveMRR never writes to your live account during seeding. Every object is created in your Stripe sandbox through the sandbox key you saved on the project, and both keys are verified to be in the right mode before anything runs.
- Preview before anything happens. After you paste the live key, MoveMRR validates it and shows what it found — how many products, coupons, promotion codes, tax rates, subscriptions, and customers — before you start.
- Idempotent re-runs. Every seeded object is fingerprinted in its metadata. If a run is interrupted, or you seed again after live data changed, objects that already exist are recognized and reused. Re-running is safe.
- One run at a time. A seeding run and a migration run never overlap on the same project, and every run is logged.
Step-by-Step Walkthrough
The full flow takes about 45 minutes of your attention. The seeding runs themselves depend on account size — roughly a minute per 100 subscriptions.
1. Create a sandbox in your live source account
In the Stripe Dashboard, open the account picker and create a sandbox under your live source account. A Stripe sandbox is the isolated test environment Stripe creates alongside your live account — nothing you do there touches live data. This will be your source sandbox.
2. Copy your customers with Stripe’s copy tool
Use Stripe’s customer copy tool to copy your customers into the new sandbox. This is a Stripe feature and Stripe handles it entirely — MoveMRR never copies customer or card data. Stripe preserves customer IDs when copying into a sandbox, which is what lets the seeded subscriptions land on the right customers in the next steps.
3. Save the sandbox key in MoveMRR
Create a sandbox project in MoveMRR, then create an API key inside the Stripe sandbox (sk_test_… or a restricted rk_test_…) and save it as the project’s source key in the Connect step. Seeding stays disabled until the sandbox key is saved.
4. Seed the source sandbox
Below the source key section you’ll find the Sandbox Seeding card. It opens a guided three-step flow:
- Prepare — confirm the sandbox exists and the customers are copied in.
- Connect your live account — paste the read-only live key. MoveMRR validates it, confirms it’s a live key with the right permissions, and shows the preview counts.
- Choose what to seed — products and prices are always seeded; coupons and promotion codes, tax rates, and subscriptions are on by default and can be toggled off.
Start the run and watch the progress on the card. When it completes, you’ll see per-entity results: created, reused, skipped, and failed — with notes for anything that needs your attention.
5. Prepare the destination sandbox
For the destination side you have two options:
- Fresh sandbox — if you want to test against a blank buyer account, just create a sandbox and save its key as the project’s destination key.
- Replicated destination — if the buyer’s live account already has customers and products, repeat steps 1–4 against your live destination account. One caveat: only copy the customers that already exist in the live destination. The migrating customers arrive in the next step, via customer sync — just like in a real migration.
6. Sync customers and generate the mapping CSV
In a real migration, Stripe copies your customers to the destination account and gives you a mapping CSV. For sandbox testing, MoveMRR mirrors that step: in the Customers step, run customer sync. MoveMRR recreates the customers behind your source sandbox’s subscriptions in your destination sandbox — each with a Stripe test card as its payment method — and generates the customer mapping CSV, already uploaded to your project.
7. Run the sandbox migration and read the results
From here, everything works exactly like the real migration described in our step-by-step guide: validate, run, and review. Because the sandboxes mirror your live accounts, the results are meaningful — price mappings that fail here would have failed in production, and a clean sandbox run is real evidence that your setup is correct.
Stripe Sandboxes vs. Sandbox Projects
Two similar terms, two different things:
- A Stripe sandbox is Stripe’s isolated test environment, created alongside your live account in the Stripe Dashboard. It has its own test API keys and its own data.
- A MoveMRR sandbox project is a project inside MoveMRR that connects two Stripe sandboxes with sandbox keys, built for test migrations.
Sandbox Seeding connects the two: it fills your Stripe sandboxes with realistic data so your MoveMRR sandbox project has something worth migrating.
Limitations and Notes
Seeding aims for fidelity, but a sandbox is not a byte-for-byte clone of a live account. Know these differences before you read your test results:
- Test cards replace real payment methods. Card data never leaves Stripe. Sandbox customers get a Stripe test card, which behaves like a valid card for testing purposes.
- Automatic tax and payment settings are intentionally not copied. A fresh sandbox has no Stripe Tax configuration and no configured payment methods, so copying those settings would make subscription creation fail. If a live subscription used automatic tax, the run notes it.
- Webhook endpoints are not seeded. If your test scenario depends on webhooks, add them to the sandbox yourself.
- Past-due subscriptions are seeded as active. A sandbox has no failed-payment history to reproduce, so past-due subscriptions are recreated as active ones. The original status is recorded in the subscription’s metadata.
- Re-seeding requires the live key again. Because the key is never stored, every new seed run starts with pasting it fresh. That’s by design.
Test First, Then Migrate
A migration you’ve already watched succeed is a migration you can run calmly. Create a sandbox project at app-movemrr.netlify.app, seed it from your live accounts, and run the full migration end to end — before the one that counts.