How to Migrate Between Shopify Subscription Apps

Migrating subscription apps is the highest-risk routine operation a subscription store performs. Done carelessly it produces a churn event that takes months to recover from.

The risk is concentrated in one question: who holds the payment method?

The question that decides everything

If Shopify holds it — both apps use native subscription contracts and Shopify’s vault — then the contracts already exist as Shopify objects. Migration means pointing a new app at existing contracts. Customers do nothing and most never notice.

If the old app holds it — the app has its own vault and drives charges through its own gateway integration — then the payment credentials are not yours to move. PCI rules restrict transferring stored card data, and in practice you are asking every subscriber to re-authorise.

That second case is a churn event, not a migration. Expect to lose a meaningful share of subscribers, because “please re-enter your card to keep your subscription” is an invitation to reconsider.

Before you commit to any subscription app, ask this question about it. It determines your exit cost.

What has to move

Even in the good case, plenty is not automatic:

• Plans and pricing — frequencies, discounts, minimum terms
• Discount configuration — especially escalating or tenure-based discounts
• Delivery schedules — next charge date per subscriber, which must not shift
• Customer portal links — old links in past emails will break
• Email templates and triggers
• Order tags and downstream automations that depend on them
• Anything referencing the old app’s metafields

That last one bites. Fulfilment rules, shipping logic and reporting often key off metafields the old app wrote. If those disappear, workflows fail silently.

The sequence

1. Audit what you have. Export every active subscription with its plan, frequency, next charge date, discount and address. You need this as a reconciliation baseline regardless of what the vendors promise.

2. Confirm the contract model of both apps. Ask both vendors directly, in writing.

3. Stop new signups on the old app before migrating. Migrating a moving target means reconciling a set that changed during the migration.

4. Migrate in a test batch. Ten subscribers, ideally including your own. Let one of them actually renew on the new app before proceeding.

5. Reconcile. Count active subscriptions before and after. Compare next-charge dates. A migration that shifts everyone’s billing date by a day generates a wave of confused emails.

6. Keep the old app installed but inactive for a billing cycle, so you can compare and fall back.

7. Communicate — but only if customers will notice. If nothing changes for them, a message saying “we’ve changed subscription systems” creates concern where there was none. If portal links change, tell them clearly.

The dates matter most

The most common visible failure is charge dates moving.

A subscriber billed on the 14th who suddenly gets billed on the 9th has been charged early, may not have funds, and will contact you. At scale that is a support crisis plus a payment failure spike.

Verify next-charge dates explicitly after migration for every contract, not a sample.

Timing

Avoid: your peak season, the days around your largest billing batch, and any period when you cannot give it attention.

Best: a quiet week, early in a billing cycle, when you can watch the first renewals land.

Afterwards

Watch for a fortnight:

• Renewal success rate versus the old baseline
• Support ticket volume and themes
• Cancellations versus the prior period
• Failed payments by decline reason

A migration that looks fine on day one and shows a payment failure spike at day fourteen has a mandate or vault problem that only surfaces at the first renewal.

Full checklist · Migrating to Super Subscription

Frequently asked questions

Will my subscribers have to re-enter their payment details if I switch apps?

Not necessarily. If both apps use native Shopify subscription contracts with payment methods vaulted by Shopify, the contracts and payment methods stay in place and migration is largely configuration. If the old app held payment methods in its own vault, customers usually do have to re-authorise.