A Shopify subscription migration is the process of moving your active subscription contracts, billing schedules, and customer payment methods from one subscription app or platform to another. The contracts and schedules move in a CSV. The payment methods usually cannot, and that single gap is what stalls most migrations.
This guide covers what a migration involves, what a stalled one costs, why payment methods get stuck, and six strategies for switching without losing subscribers, drawing on what we see running subscriptions on Shopify every day.
Recurly data: when a failed payment is recovered, the subscriber stays a median of 141 more days (State of Subscriptions).
What is a Shopify subscription migration, and why do payment methods make it hard?
A subscription migration re-creates your active subscription contracts inside a new app: the products, the delivery cadence, the price each subscriber locked in, the discounts, and the next billing date. Done right, your customers notice nothing. Their box still arrives, their card is still charged on the same day of the month.
The hard part is the payment method. A subscriber's card is not stored in your old subscription app as a number you can export. It lives in a payment vault as a token, and that token belongs to whoever created it. If your old platform billed cards through its own gateway account, the new app cannot charge that token. This is why migrations that look like a simple data export turn into a payment-methods project.
Subscriptions feel this harder than one-time stores because the relationship is the asset. A one-time store that switches apps loses nothing; a subscription store that fumbles a migration can lose recurring revenue it already earned.
What a stalled migration actually costs you
The cost of a bad migration is not the software bill. It is the involuntary churn you create when contracts arrive without a way to bill them.
- Industry benchmarks attribute roughly 20% to 40% of all DTC subscription cancellations to failed payments rather than customer choice, per Recurly's State of Subscriptions research. A migration that strands payment methods can push you toward the top of that range, because every migrated contract without a card is a billing failure waiting to happen.
- The upside of getting payments right is equally concrete: Recurly data shows that when a failed payment is recovered, the subscriber stays a median of 141 more days, nearly five extra months of revenue.
- Merchants with automated payment retry and dunning recover about half of failed-payment revenue, with Recurly reporting a 49% median recovery rate. Merchants with nothing in place recover far less, and a mid-migration store often has nothing in place.
None of these numbers are promises, and medians hide wide ranges. But the direction is consistent: the money in a migration is won or lost at the payment layer, not the product layer.
Why do payment methods get stuck when you switch subscription apps?
Four root causes account for almost every stuck migration.
1. Gateway tokens are not portable
Saved cards exist as vault tokens owned by the platform or gateway that created them. Some providers will export tokens to another vault on request; others will not, and the process can take weeks either way.
2. The old platform billed outside Shopify
If your previous subscription tool charged cards through an external gateway rather than Shopify's checkout, there is no token in Shopify's vault at all. Shopify-native subscription apps bill through Shopify, so every one of those customers needs a card saved with Shopify before billing can resume.
3. Customers have to act, and most act slowly
When a card cannot be transferred, the customer has to re-enter it. Some do it the same day. Many do it after their next delivery fails to arrive. A migration plan that assumes fast customer action will overestimate its first month badly.
4. All-or-nothing importers
Many importers reject any row without a valid payment method, which forces you to wait until every customer has re-vaulted a card before importing anyone. The store runs two systems in parallel for weeks, and every day of parallel running creates support tickets and double-billing anxiety.
Should you migrate at all? An honest check first
One caution before the playbook. Subscription expert Matthew Holman cautions that switching subscription platforms rarely fixes high churn, because the usual causes are the offer, onboarding, and lifecycle messaging rather than the software. If your reason for migrating is churn itself, audit the program first; the churn usually travels with you. Migrate for a genuine capability gap: a plan type your current app cannot model, missing recovery tooling, dunning you cannot configure, or pricing that no longer fits your volume.
6 strategies for a subscription migration that keeps subscribers
Map the contract data before you export
List every field your subscriptions depend on: product and variant, cadence, locked-in price, discounts, shipping profile, and above all the next billing date. Pull one clean export from the old system and reconcile the count of active contracts against what the old dashboard reports. Every mismatch you find now is a support ticket you avoid later.
Ask your old provider about token portability early
If your previous platform billed through Shopify's checkout, tokens may already be usable. If it billed externally, request a vault export in the first week of the project, not the last; the answer determines the shape of everything below.
Import contracts first, even the card-less ones
This is the step that has historically forced the long way around. Subi's importer now accepts contracts with the
payment_method_idcolumn left blank: the contract imports active, with its price, cadence, and next billing date intact, and no card attached yet (how card-less import works). The subscription relationship is established on day one instead of after weeks of waiting, and there is no parallel-running window.Let the platform ask for the cards
Chasing card-less customers manually does not scale past a few dozen contracts. After a Subi import run finishes, customers whose new contracts have no payment method automatically receive a payment-request email, one email per customer rather than per contract (details). The first card a customer saves attaches to their contract automatically, and billing proceeds from the next billing date.
Never move billing dates in the switch
Nothing erodes subscriber trust faster than a surprise charge on a new date. Carry each contract's existing next billing date through the import unchanged, and let billing resume on the schedule the customer already agreed to. Once the card attaches, billing proceeds from the contract's next billing date.
Turn on payment recovery from day one
A freshly migrated base will throw more payment failures than a settled one, so recovery tooling matters most in the first two months. Automated retries, decline-aware timing, and reminder messages are the difference between a failed charge and a cancelled subscriber; this is where the 49% median recovery figure above, measured across Recurly's mid-market-heavy base, is earned. If you inherit failure-prone contracts, treat reducing involuntary churn as part of the migration project, not a later optimization.
How Subi specifically helps
Subi's migration tooling was built around the payment-method gap described above:
- Card-less contract import. The CSV importer accepts rows without a
payment_method_id, creating active contracts that bill as soon as a card arrives. The format is unchanged; a blank cell is now a valid choice rather than an error (changelog). - Automatic payment-method requests. After every import run, Subi identifies migrated customers with no card on file and emails them a payment-method request, scoped to that run so existing customers are never mailed by mistake (changelog).
- Smart Payment Recovery. Once contracts are live, Subi classifies each failed payment by its decline reason and routes it to the fix that matches: scheduled retries for temporary failures and a one-click backup-card switch, and on Subi Plus, an email asking the customer to update an expiring card before the next charge runs (how payment recovery works).
Solve this with Subi.
Frequently asked questions
Can I migrate subscriptions to Shopify without customers' payment methods?
Yes. Subi imports contracts with the payment-method column left blank; each contract is created active, the customer is emailed to add a card, and the first card they save attaches automatically (changelog). Billing starts from the contract's next billing date once a card exists.
Do customers have to re-subscribe when I switch subscription apps?
No. A migration re-creates existing contracts; customers keep their plan, price, and schedule. Depending on how your old platform stored cards, some customers may need to re-enter a payment method, which is a much smaller ask than re-subscribing from scratch.
Will my subscribers' billing dates change during a migration?
They should not. Carry each contract's next billing date through the import and let the new app bill on the existing schedule. In Subi, an imported contract bills from the next billing date in its row, so the customer's cadence is preserved.
How long does a subscription migration take?
The data work is typically days. The long tail is payment methods: token exports from a cooperative provider take days to weeks, and customer re-vaulting stretches with your list. Importing contracts first and automating the card requests removes most of the calendar risk, because the wait no longer blocks the cutover.