Stripe Sandbox Seeding for Migration Rehearsal

An empty Stripe sandbox can prove that buttons work. It cannot prove that your migration will work.

Sandbox Seeding gives a MoveMRR sandbox project the catalog, discounts, tax rates, customers, and subscription shapes needed for a useful end-to-end rehearsal. It reads your live accounts with one-time keys, writes only to the corresponding Stripe sandboxes, and then creates the customer mapping needed to migrate between those sandboxes.

This is an optional branch from the main migration guide. If both Stripe sandboxes already contain representative data, skip this article and continue with Catalog.

First, Know Which Account Is Which

You will work with four Stripe environments:

Role	Environment	What it represents	What MoveMRR does
Source live	Live	Seller’s current billing account	Reads it once to discover data
Source sandbox	Test	Rehearsal version of the seller account	Creates the source test catalog and subscriptions
Destination live	Live	Buyer’s current Stripe account	Reads it once to discover pre-existing data
Destination sandbox	Test	Rehearsal version of the buyer account	Creates the destination’s pre-existing test data

The source and destination live accounts are never migration targets during seeding. All writes go to their Stripe sandboxes.

What You Need

Before opening the Seeding workspace, make sure:

• You created a Sandbox migration in MoveMRR. Live projects cannot open the seeding route.
• The source and destination cards on Connect contain the correct stored Stripe test keys.
• You have administrator access to both live Stripe accounts and both Stripe sandboxes.
• Two-step authentication is enabled where Stripe requires it to create restricted keys.
• No migration run or seeding run is active on the project.
• You can identify each account by its acct_… ID, not just its display name.

MoveMRR uses two different key types for each side:

1. A read-only live key (rk_live_… or sk_live_…) to scan the live account.
2. A write-capable sandbox key (rk_test_… or sk_test_…) to create the discovered data in the matching Stripe sandbox.

Both are validated for the current run and cleared after the run starts. They are separate from the stored source and destination keys used by the migration pipeline.

What Gets Seeded

Entity	Behavior
Products and prices	Always selected. They are the dependency foundation for subscriptions and discounts.
Coupons	Optional and selected by default. Existing fingerprinted objects are reused.
Promotion codes	Optional and selected by default. Codes that cannot be recreated are reported as skipped or failed.
Subscriptions	Optional and selected by default. Recreated against sandbox customers and mapped test prices.
Tax rates	Optional and selected by default. Stripe creates new test IDs; MoveMRR tracks the mapping.
Customers	Created in the destination by Customer sync, not by a source/destination seed toggle.
Payment methods	Real card data is never copied. Customer sync attaches Stripe test payment methods.
Stripe webhook endpoints	Not seeded. Configure them separately if your rehearsal depends on webhook delivery.

Seeding is designed to be repeatable. Objects carry fingerprints so completed work can be reused instead of duplicated. Still, always inspect Created, Reused, Skipped, and Failed counts after every run.

Step 1: Open the Seeding Workspace

Open the sandbox project and select Connect in the stage rail.

Below the two key cards, find Sandbox seeding and select Open workspace. The workspace has three URL-backed tabs:

• Source
• Destination
• Customer sync

Refreshes and copied links preserve the selected tab.

If MoveMRR redirects you back to Connect, verify that the project itself was created as Sandbox. Adding test keys to a Live project does not convert its environment.

Step 2: Seed the Source Sandbox

Open the Source tab. The page is deliberately divided into validation, entity selection, and execution.

2.1 Generate the source live key

Under 1 · Validate live key, select Generate restricted key….

Before following the Stripe link, verify:

• You are signed into the seller’s live Stripe account.
• The account ID shown in Stripe matches the source live account.
• Stripe is in live mode, not a sandbox or test-mode view.

The generated key should grant read access to the entities shown in MoveMRR’s permission matrix: customers, subscriptions, products, prices, coupons, promotion codes, and tax rates.

Copy the key, paste it into Read-only source live key, then select Validate live key.

2.2 Review validation and preview counts

A successful validation shows:

• Live account scanned
• The live acct_… ID
• A LIVE badge
• A permission matrix
• Preview counts for products, coupons, promotion codes, subscriptions, tax rates, and customers

Treat 100+ as “the preview page was truncated,” not as an exact total. The complete count becomes known during the seeding run.

Stop if:

• The account ID is wrong.
• The badge says TEST.
• A required permission is missing.
• Counts are implausibly low or zero for a populated account.

Edit the key or its permissions, then validate again.

2.3 Generate and validate the source sandbox key

In the same card, continue to the sandbox key section and select the sandbox-key generator.

In Stripe, confirm you are inside the source sandbox. Create a restricted test key with the requested write permissions, copy it, and paste it into MoveMRR.

Select Validate sandbox key. A successful result shows:

• Sandbox writes validated
• The source sandbox acct_… ID
• A TEST badge
• The write-permission matrix

This second validation prevents the most serious seeding error: scanning the correct live account but writing the result into the wrong sandbox.

2.4 Choose entities

Products and prices are always selected.

Keep Coupons, Promotion codes, Subscriptions, and Tax rates selected for the closest production rehearsal. Clear an entity only when you intentionally want to exclude it and understand what that removes from the test.

Examples:

• Clearing Subscriptions produces catalog data but gives the migration nothing to move.
• Clearing Coupons can hide discount mapping failures.
• Clearing Tax rates can hide tax-rate references used by subscriptions.

2.5 Start and inspect the run

The Start seeding run button becomes available only after both one-time keys pass validation and no source seeding run is active.

Select it and monitor the run card. Discovery can briefly show an indeterminate progress state while MoveMRR calculates total work. During execution, the card reports processed and total items.

When terminal, expand the run and review:

• Created
• Reused
• Skipped
• Failed
• Per-entity notes
• Item errors and source IDs

The displayed item-error list is capped at 200 entries. A cap notice means more errors may exist than are rendered.

Do not continue to Customer sync until at least one source run is Completed. A completed run can still contain skipped items, so investigate the entity results first.

Step 3: Seed the Destination Sandbox

Open the Destination tab and repeat the same sequence for the buyer side:

1. Generate and validate a read-only key in the destination live account.
2. Verify the returned live account ID and preview counts.
3. Generate and validate a write-capable key in the destination sandbox.
4. Choose entities.
5. Select Start seeding run.
6. Expand the terminal result and review created, reused, skipped, and failed items.

Why seed the destination too? A buyer account is rarely blank. Its existing catalog, coupons, customers, and identifiers are what expose collisions and incorrect assumptions during a real migration.

Even if you want an almost-empty destination rehearsal, complete a destination seed run with the intended entity selection. The current Customer sync gate requires completed source and destination seeding evidence.

Do not seed the migrating source customers directly into the destination sandbox. Customer sync handles those in the next step and generates the authoritative old-to-new mapping.

Step 4: Run Customer Sync

Open Customer sync.

This tab does not ask for either live key. It uses the source and destination sandbox keys already stored on Connect.

The Run customer sync button lists every unresolved blocker. It requires:

• A stored source sandbox key
• A stored destination sandbox key
• A completed source seeding run
• A completed destination seeding run
• No active customer-sync run

Select Run customer sync.

MoveMRR:

1. Finds the customers behind the seeded source subscriptions.
2. Reuses matching destination sandbox customers when safe.
3. Creates missing destination sandbox customers.
4. Attaches Stripe test payment methods.
5. Generates the source-to-destination customer mapping CSV.
6. Registers that CSV as an upload on the project.

Re-running customer sync is safe: existing customers are reused instead of duplicated.

After completion, select Open upload → on the run card. MoveMRR takes you directly to Customers with the generated upload selected.

Step 5: Verify the Seeded Rehearsal Data

Before returning to the main migration path, make a short reality check in Stripe:

• Source sandbox products and prices resemble the live source catalog.
• Source sandbox subscriptions exist and reference the expected test customers and prices.
• Destination sandbox contains the buyer-side objects you intended to reproduce.
• Customer sync created or reused the expected number of destination customers.
• The generated mapping upload is marked Valid in MoveMRR.
• Payment-method coverage uses Stripe test methods and has no unexplained gaps.

A clean “Completed” status means the run reached its end. It does not mean every source object was recreated. Skipped and failed entity counts are part of the result and must be reviewed.

Safety Model

Sandbox Seeding follows five boundaries:

1. Live reads only. The live key is used to scan; seeding never writes to a live Stripe account.
2. Sandbox writes only. The one-time sandbox key must validate as Test mode.
3. Keys are one-time inputs. Live and sandbox keys used for a seed run are cleared after the run starts and are not persisted as seeding credentials.
4. Preview before execution. Live validation shows account identity, permissions, and discovery counts before a run can start.
5. One operation at a time. Active seeding and migration operations are gated to avoid competing writes.

Common Problems

“Validate a live key first”

The key was not validated, changed after validation, failed permissions, or is in Test mode. Paste a live-mode key and select Validate live key again.

“Validate a write-capable sandbox key first”

The second key is missing, in Live mode, belongs to the wrong sandbox, or lacks one of the required write permissions. Generate it from the current Source or Destination tab and validate it there.

Preview says 100+

The preview reads only the first page of that Stripe resource. It is a lower bound, not an error and not the final total.

Start is disabled

Read the blocker list below the button. The UI names the missing validation or active run. Resolve every listed item; do not repeatedly click the disabled action.

The run is stalled

Check the heartbeat warning on the run card, then use Refresh. If the run remains active without a fresh heartbeat, keep its run ID and contact support before starting another operation.

Customer sync is disabled

Confirm both sandbox keys are stored on Connect and both Source and Destination have at least one completed seed run. The blocker list identifies the missing prerequisite.

The generated CSV is not visible

Expand the completed Customer sync run. Open upload → appears only when the run completed and produced a csv_upload_id. Refresh the run list if the card still shows an active status.

Sandbox Fidelity Limits

A sandbox is a rehearsal, not a byte-for-byte clone:

• Real payment credentials never leave Stripe; test payment methods replace them.
• Webhook endpoints are not seeded.
• Account-level Stripe Tax, payment-method, branding, and business settings are not cloned.
• Failed-payment history and every invoice state cannot be reproduced exactly.
• Stripe may assign new IDs to recreated objects; MoveMRR records mappings and fingerprints.
• External systems that react to Stripe webhooks need their own sandbox configuration.

Interpret the rehearsal accordingly: it is strong evidence for catalog mappings, customer mappings, subscription creation, configuration, and run behavior. It is not proof that unrelated account-level settings are identical.

Return to the Main Migration

Seeding and customer sync are now complete. Continue with:

1. Catalog — map or auto-create the migration catalog.
2. Customers — keep the generated customer-sync upload selected and verify payment-method coverage.
3. Configure — review source deactivation, billing cycles, trials, metadata, and scope.
4. Rehearse — validate readiness, dry run, and simulate.
5. Launch — execute the sandbox migration.
6. Verify — reconcile the two sandboxes and inspect follow-ups.

Return to the main guide at Catalog →

Related Resources

• MoveMRR product manual
• Restricted Stripe API Keys
• Stripe Customer Data Copy
• Preventing Double Billing