Shopify Subscription Migration Without Losses

Your subscriber count in the new app matches. Your revenue does not. A week after the move, support is fielding two kinds of email: people charged twice, and people whose box never came. Somewhere in the export, contracts lost their place in the cycle and others lost the price they were promised in 2024.

That is where a Shopify subscription migration goes wrong. Not the export. The export is a CSV and it works. What breaks is state: the things between the rows. A payment token in a vault you do not control. A next billing date that is really an anchor plus an interval plus a timezone. A price hand-edited once that exists nowhere in your catalogue.

This is a runbook for moving subscribers without losing any of that.

What actually gets lost when subscriptions move between apps?

Start by writing down what you hold. The rows that go missing are rarely the ones you were watching.

The pattern: anything Shopify itself knows tends to travel. Anything the old app decided on its own does not. Every row in that second group you carry by hand or consciously accept losing.

Can payment methods move, or must customers re-authorise?

This decides whether your migration is a weekend or a quarter. Answer it first.

• Shopify-native to Shopify-native. If both apps create Shopify subscription contracts against the same Shopify Payments account, the saved payment method belongs to the shop. Shopify creates the contract at checkout as part of the selling plan flow.
• App-owned vault to a different processor. If your current app bills through its own merchant account, the card numbers sit in that processor's vault. You cannot export them. Moving them is a formal, PCI-scoped transfer, scheduled by them, not you. Open the request with both processors before you tell subscribers anything. Lead times are the biggest reason migrations slip.
• Re-authorisation is the last resort. Every customer asked to re-enter a card is given a reason to reconsider. If you must, do it in waves tied to each subscriber's renewal date.

If tokens cannot move, stop and re-plan. That is not a detail to discover on cutover morning.

How do you preserve next-billing dates and position in the cycle?

A next billing date is not one field. It is an anchor date, an interval, a count of cycles already run, and a timezone the old app assumed.

Export all four and set the date explicitly on import. Let the new app derive it from a fresh anchor and a customer on day 3 of a 30-day cycle gets billed tomorrow.

• Normalise the timezone. Store everything in UTC during the transfer and convert once at import. A few hours of drift crosses a day boundary for part of your book.
• Count prepaid deliveries. A twelve-month prepaid contract with four boxes shipped is not a new one. Carry the remainder and check it against fulfilments.
• Preserve the anchor day, not just the interval. Someone billed on the 1st stays on the 1st. Month-end anchors need an explicit rule for February.
• Sort your export by next billing date. It doubles as your batching plan and your risk map. Anything due in the next 72 hours is the dangerous set.

What happens to legacy pricing and discounts on old contracts?

Old contracts hold old prices by design. Updates to a selling plan do not modify contracts that already exist in Shopify's model. So your 2024 subscribers can be paying a price that appears in no plan, no product and no discount rule in your store.

That price exists only on the contract row. Export selling plans instead of contracts and it is gone.

Build one selling plan per distinct legacy price and map each contract to the plan matching what it pays today. Ugly in the admin. Correct in the bank account.

How do you avoid double-charging or skipping a cycle at cutover?

One rule holds this together: exactly one system is authoritative at any instant. Double charges come from the window where both apps think they own the same contract.

1. Disable billing in the old app first. Before you export, not after you import.
2. Take the export immediately after the freeze. A stale export is a wrong export.
3. Import with billing disabled in the new app too. Load, verify, then enable charging.
4. Diff the dates before you enable. Compare the last charge in the old app against the next charge in the new one. If the old app already billed this cycle, push the new date forward a full interval.
5. Prefer skipping. When a contract is ambiguous, skip the cycle. You can bill a week late with an apology. You cannot un-charge without a refund and a chargeback risk.
6. Hold back the dangerous set. Contracts due within 72 hours of the freeze get migrated and checked by hand.

What does the cutover week look like, hour by hour?

Do it on a low-volume day, with the team awake, and never before a holiday.

That gap between import and enabling billing is the last cheap moment to catch a mistake.

How do you reconcile the two systems after the move?

Reconciliation is three counts and a histogram. Run them before you enable billing and again a week later.

• Contract count. Active in the old app on freeze day versus active in the new one. Explain every difference line by line.
• Recurring revenue in minor units. Sum the per-contract charge on both sides as integers. A difference means a legacy price did not carry.
• Next-billing-date histogram. Bucket contracts by date on both sides. A spike on one day means the new app re-anchored a group instead of preserving their dates.
• Per-customer diff for the tail. Your largest subscribers get checked by a human against the old admin.

Then watch declines. Dunning retry state does not carry, so a card that was mid-retry arrives looking healthy and fails on first attempt. Expect a bump in week one. Separate genuine failures from migration artefacts before chasing anyone. If declines have not settled by the second cycle, the problem is not dunning. It is a mapping error.

What do you tell subscribers, and when?

Tell them before, in plain language, and only about what affects them.

• First email, three days out. What is changing, the date, and what they must do. If the answer is nothing, say so.
• Second email, the day after. The new portal link and how to manage a subscription. This is the one that cuts support volume.
• Never promise nothing will change if the portal login, the charge descriptor or a billing date moves. Being caught understating it costs more than the change.
• Handle re-authorisation separately. If some customers must re-enter a card, that is its own email to that segment, timed to their renewal. Never bury it in a general announcement.
• Brief support first. Export open and a one-page script before the first email goes out.

What is the rollback plan if it goes wrong?

Decide your abort criteria at T-24h, in writing, while you are calm: a handful of unexplained contract differences, a revenue mismatch you cannot account for, or any evidence of a duplicate charge.

Keep the old app installed with billing disabled for at least a full cycle plus the dunning window. Rolling back then means re-enabling billing there and disabling it in the new app. Five minutes, because you deleted nothing.

The point of no return is the first successful charge in the new system. After that, rolling back means refunding real money and re-vaulting real cards, so you forward-fix instead: correct the affected contracts, refund the affected customers, keep going. That is why reconciliation sits before the billing switch.

Where does Edge Subscriptions fit in a Shopify subscription migration?

This is mostly a data problem. App features matter less than whoever does the mapping. Be sceptical of any app that pitches migration as a button.

Edge Subscriptions is new. It has no review history and I will not pretend otherwise. It builds on Shopify's native subscription contracts, so the payment method stays with the shop and the easy case above stays easy. It handles subscribe and save, the customer portal, and dunning.

If you are moving thousands of contracts off a processor-owned vault, what you need most is a team that has done that transfer before. Recharge is the most established option there at 4.8 stars across 2,967 reviews, and it has no free plan. If your book is small and cost decides it, Appstle has a free plan up to $500 per month in subscription revenue. Our Appstle comparison and the app roundup go deeper.

Edge fits if you have outgrown a basic setup, want native contracts and a portal that does not fight your theme, and want legacy prices handled one at a time. If that is not you, use one of the others.