How to Migrate Shopify Subscriptions Without Losing Subscribers

The vendor will tell you the migration is done in a week and you will not lose a single subscriber. The first half is roughly true. The second half is where I get the panicked message, usually about ten days after cutover, when cancellations tick up and nobody can say why.

TL;DR: Moving between Recharge, Skio, and Loop is a solved problem on the vendor side: their teams migrate the contracts, customers, and billing dates. Subscribers churn for theme-side reasons instead. A dead customer portal link, a failed first charge, a silent customer email. Get the dev work and the comms right and a switch costs you almost no subscribers. Skip them and you bleed retention with no error to point at.

Why this matters for your store

• Subscribers are your highest-LTV customers, so a migration that quietly drops even 3% of them costs more than the app fee you were trying to save.
• The contract transfer is the part everyone watches and the part that rarely fails. The failures hide in your theme and your inbox, where no dashboard flags them.
• A clean switch is mostly QA and customer comms, not engineering, which means it is cheap to do right and expensive to do blind.

What actually migrates automatically, and what does not

The first thing to fix is the assumption that “the vendor handles the migration” means everything is handled. The vendor handles the database. Your storefront is your problem.

All three apps now run on Shopify’s native selling plan API, so the receiving vendor (Recharge, Skio, or Loop) can run a managed migration that pulls your subscription contracts and re-creates them on their platform. Here is the honest split of what that managed service covers and what lands on you.

The pattern is clear. The data moves. The presentation layer, the part your customer actually touches, does not move with it.

How long it takes and what the cutover looks like

A realistic timeline is 14 to 21 days from signed contract to the first billed cycle on the new app. It is not a same-day flip, and pretending it is causes the rushed cutovers that drop subscribers.

1. Days 0 to 4. Contract signed, receiving vendor pulls the export from your current app.
2. Days 5 to 9. Test contracts in a sandbox. Confirm billing-date alignment, payment-method validation, and the edge cases: paused subscriptions, prepaid balances, gift subscriptions.
3. Day 10. Cutover. Pause new sign-ups for roughly 24 hours, transfer contracts, repoint the portal, and 301-redirect the old portal URL for a year.
4. Days 11 to 21. Send the customer notification, monitor the first billing cycle, and test failed-payment recovery.

Existing subscriptions keep billing throughout. Only new sign-ups pause during the 24-hour cutover, so a shopper buying a one-time product sees nothing.

What breaks in your theme on migration day

This is my lane, and it is the part the vendor migration plan never mentions because it is not their job. On every subscription migration I have done, the same three things break in the theme.

First, the PDP widget. The old app’s block is gone and the new one needs placing. If you ran the vendor’s default widget, this is a settings change. If you built a custom subscription UI reading selling_plan_allocations directly, like the Liquid pattern in the Recharge vs Skio vs Loop comparison, the data shape survives but the selling-plan-group IDs do not. Any ID you cached in a snippet or a metafield is now pointing at nothing.

Second, CLS comes back. The new widget injects radios and a frequency dropdown into the form area, and if your reserved-space container was tuned to the old widget’s height, the new one shifts the price on hydration. A subscription widget is one of the most common layout-shift sources on a PDP, and a migration is a fresh chance to reintroduce it. Re-measure with the Performance API and reset the min-height on the slot.

Third, the customer portal URL changes. The link in your header, your account page, your post-purchase emails, and your “manage subscription” buttons may now 404. This is the single biggest silent churn driver, because a subscriber who cannot find how to skip or swap a delivery does not email you. They cancel.

The real churn cause is silent, and it is not the contract

Here is what the vendor pitch gets backwards. The contract transfer is the safe part. It runs in a database, it gets tested in a sandbox, and if a contract fails to import, it shows up as an error someone fixes.

The churn comes from two failures that throw no error at all. A failed first charge on a payment method that did not re-authorize cleanly, which silently lapses the subscription unless your dunning is configured. And a customer who hits a dead portal link, cannot manage their plan, and cancels out of friction. Neither shows in the migration report. Both show up two weeks later as a retention dip, which is exactly the post-purchase friction that quietly leaks revenue everywhere else on a store.

So the migration QA that matters is not “did the contracts move.” It is “can a real customer still manage and pay for their subscription the day after.”

How to keep customers from churning during the switch

Two moves, neither of them engineering, both skipped more often than not.

Send a plain, short email before cutover. Tell subscribers their subscription is moving, nothing changes for them, and here is the new link to manage it. A silent migration generates support tickets and cancellations; a one-paragraph heads-up prevents both, the same way a tight cart-recovery sequence beats a noisy one. Write it at a grade-4 reading level, no jargon, one button.

Then confirm failed-payment recovery is live before you switch off the old app. The first billing cycle on the new platform is where re-authorization problems surface. If dunning is not configured, a soft card decline becomes a churned subscriber instead of a retry. Watch the first cycle like a launch.

The migration QA checklist

Run these the day of and the day after cutover. None need the vendor.

1. Open a real subscriber account on the live site and confirm the manage-subscription link resolves, not 404s. Test skip, swap, and cancel.
2. Load a subscription PDP on a 390px phone and confirm the widget renders with no price shift. Re-check the reserved min-height if it does.
3. Place a test subscription end to end and confirm the contract appears in the new app with the correct next-billing date.
4. Grep your theme and metafields for any hardcoded selling-plan-group ID from the old app and re-map it. The IDs changed.
5. Confirm the first real billing cycle charged successfully and that a soft decline triggers a retry, not a silent lapse.

The takeaway

• The vendor moves the data; you move the storefront. Budget the theme and comms work, not just the contract export.
• Repoint and 301 the customer portal URL first. A dead manage-subscription link is the top silent churn driver in a migration.
• Re-check CLS on the PDP widget. A new widget reintroduces layout shift if the reserved space was tuned to the old one.
• Re-map cached selling-plan-group IDs. The native data shape survives the move, the IDs do not.
• Email subscribers before cutover and watch the first billing cycle. Silent migrations and unconfigured dunning are where the subscribers actually go.

Switching apps for the right reason (cost, data, or fit, covered in the full comparison) is worth doing. Just treat it as a CRO project with a QA plan, not a database export.

Kaspian Fuad is a Shopify CRO consultant and Liquid developer who builds and migrates subscription and retention flows for DTC brands. 12 years in ecommerce, 100+ stores, Top Rated Plus on Upwork. Book a free 30-minute call if you want a second pair of eyes on a subscription migration before you cut over.