A subscription migration moves live billing relationships, not records. Get the payment token migration or the billing anchors wrong and the damage surfaces a full cycle later — as involuntary churn nobody connects back to the project.
Most migrations are reversible in spirit: if a product page is wrong you fix it and move on. A subscription migration is not like that. You are moving live financial mandates, and the failure mode is silent. Everything looks fine at launch because nothing bills at launch. The damage appears at the next cycle, by which point the project is closed and the churn gets attributed to "the market".
Payment tokens decide whether this is possible
Establish this before anything else, because it can end the project. Stored payment credentials are held by a payment processor and vaulted against a specific merchant and gateway configuration. Whether those tokens travel depends on staying within the same processor and on that processor supporting a vault migration.
- Same processor, same merchant account: tokens usually transfer, subject to a formal request and lead time. Start it early — these take weeks, not days.
- Different processor: tokens do not transfer. A PCI-compliant vault-to-vault migration may be possible between providers; otherwise every subscriber must re-authorise.
- If re-authorisation is required, model the loss honestly. Asking subscribers to re-enter card details typically loses a meaningful share of them, and no amount of email sequencing eliminates that.
Preserve the billing anchor
Every active subscription has a next billing date and a cycle. Migrating without preserving both is how subscribers get charged twice in a month, or skipped entirely. Double-charging generates chargebacks and support load; skipping generates a revenue hole that is hard to spot and awkward to correct.
Anchors must be migrated exactly — including subscriptions that are paused, in a dunning state, or mid-way through a prepaid term. Those three categories are where the edge cases live, and they are usually the ones missing from the test plan.
Five-phase subscription migration plan. Phase one: confirm payment token portability with the processor in writing and audit every subscription state. Phase two: map the data model including anchors, cycles, discounts, prepaid terms and dunning states. Phase three: migrate a pilot cohort of under one hundred subscribers and let them bill at least one full cycle. Phase four: migrate the remainder in batches by billing date, oldest anchor first. Phase five: monitor involuntary churn, failed payment rate and support contacts against a pre-migration baseline for three full cycles.
- Phase 1
Establish feasibility
Weeks 1–2- Written confirmation of token portability from the processor
- Audit every subscription state — active, paused, dunning, prepaid, cancelled-but-restorable
- Count subscribers by state; the awkward states drive the plan
- Phase 2
Map the model
Weeks 2–4- Billing anchors, cycle length, and next charge date per subscription
- Discounts: one-off, recurring, and those that expire after N cycles
- Prepaid terms with remaining deliveries
- Dunning state and retry position
- Phase 3
Pilot and bill it
Weeks 5–8- Migrate under 100 subscribers across every state category
- Let them bill at least one full cycle on the new system
- Reconcile every charge against what the old system would have taken
- Phase 4
Migrate in batches
Weeks 9–12- Batch by billing date, oldest anchor first, so problems surface soonest
- Keep the old system readable — not writable — throughout
- Halt criteria agreed in advance and actually enforced
- Phase 5
Watch the real metric
3 billing cycles- Involuntary churn versus pre-migration baseline
- Failed payment rate by cohort
- Support contacts mentioning billing
- Do not declare success before three full cycles
Dunning parity is a revenue control
Retry logic is quietly one of the most valuable pieces of a subscription programme. How many retries, spaced how, with what messaging, and what happens on final failure — that configuration is the difference between recovering a failed payment and losing a customer to an expired card.
Migrations routinely ship with default retry settings because nobody documented the old ones. The result is a churn increase that looks like a market shift and is actually a configuration change. Export the old dunning configuration before decommissioning anything, and replicate it deliberately.
The B2B variant
Recurring B2B supply has two differences that break assumptions built for consumer subscriptions. Billing is often on invoice and net terms rather than a stored card, so "payment token" migration is replaced by preserving terms, credit limits and PO references. And quantities vary per delivery against a contract, so the subscription is a scheduled entitlement rather than a fixed repeat order.
If that describes your programme, validate that the target platform models variable-quantity, invoice-billed recurring orders before committing. Several subscription tools are built squarely for consumer replenishment and will not express it without significant custom work.
Key takeaways
- Confirm payment token portability with the processor in writing before scoping anything else.
- Migrate billing anchors exactly, including paused, dunning and prepaid subscriptions.
- Pilot with under 100 subscribers and let them complete a real billing cycle before proceeding.
- Export and replicate the old dunning configuration — default retry settings quietly raise churn.
- Baseline involuntary churn beforehand; it is the clearest signal of whether the migration worked.
360 Expert Solutions
E-commerce & ERP Integration Team
We build and scale B2B and DTC commerce on Shopify Plus, BigCommerce and WooCommerce, wired into NetSuite and Oracle. These articles are written by the engineers and architects who deliver those projects.
Building something like this?
We architect B2B commerce and ERP integrations end to end.