The direct answer
Subscriptions attached to schedules need phase-level review. MoveMRR can identify and recreate supported schedule behavior, then release or deactivate source-side schedule control as configured. Every future phase must have valid destination prices, dates, discounts, and behavior; unsupported phase data should stop automatic acceptance.
Reviewed July 24, 2026 by the MoveMRR product team.
Migration behavior: Stripe Subscription Schedules
A Stripe Subscription Schedule can encode future catalog, quantity, discount, tax, and timing changes. The destination plan must preserve the approved phase sequence rather than flattening the subscription to its current state. Source schedule release and subscription deactivation must be ordered carefully.
What the readiness review must verify
Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run.
- Every current and future phase is present in the inventory.
- All phase prices, quantities, coupons, taxes, and dates have destination equivalents.
- End behavior and phase transitions match the intended contract.
- Source schedule release/deactivation cannot create a second active billing path.
The primary failure mode to control
Creating only the current subscription state discards contracted future changes. Releasing or canceling the source schedule in the wrong order can also leave the source subscription active or change its behavior.
Stripe Subscription Schedules: source-to-destination checks
| Check | Required evidence | If it fails |
|---|---|---|
| Phase coverage | All future phases mapped | Hold schedule for review |
| Dates | Destination sequence matches approved timeline | Correct phase configuration |
| End behavior | Release/cancel behavior is intentional | Manual decision |
| Source control | No competing source schedule remains | Block completion |
A controlled workflow
- 1
Verify the first prerequisite
Every current and future phase is present in the inventory.
- 2
Verify the second prerequisite
All phase prices, quantities, coupons, taxes, and dates have destination equivalents.
- 3
Test representative examples
Use sandbox data that includes the difficult records, not only the happy path.
- 4
Control the primary failure mode
Creating only the current subscription state discards contracted future changes. Releasing or canceling the source schedule in the wrong order can also leave the source subscription active or change its behavior.
- 5
Reconcile after creation
Compare destination behavior with the approved source-state and monitor the next event.
Limits to verify before migration
- Complex or unsupported phase fields can require manual migration.
- Schedule APIs and supported parameters change with Stripe versions.
- A scheduled future price still needs a valid destination catalog object.
- Application logic reacting to schedules must be tested separately.
Frequently asked questions
Can subscriptions with future price changes be migrated?
They can be reviewed when those changes are represented in schedule phases and every destination dependency is mapped.
What if a schedule has an unsupported phase field?
The record should be held for manual review rather than silently flattening or dropping the field.
Does Stripe’s Toolkit use schedules?
Stripe documents that its Billing Migration Toolkit uses Subscription Schedules and holds scheduled subscriptions before they go live.