Shopify Subscription App Migration: How to Switch Without Losing Subscribers

Migration fear is why you’re overpaying for your subscription app.

There’s a number most merchants can quote — what their subscription app costs them every month in fees — and a decision they keep not making, which is to leave. The gap between the two is usually fear, and that fear is rational: a subscription migration isn’t like swapping a theme. Merchants can switch subscription platforms, and Shopify officially supports it. But migrating subscriptions means far more than exporting a customer list — active contracts, billing dates, legacy pricing and payment authorizations all have to survive the move intact. This is the technical resource for doing that safely: what actually moves, what needs verification, and what continuity depends on.

Shopify subscription migration at a glance

Can Shopify merchants switch subscription apps? Yes. Migrating onto Shopify’s native subscriptions is officially supported and staged, and any app built on Shopify’s Subscription Contracts can receive migrated subscriptions.

Can subscribers be preserved? In most cases, yes — existing subscribers can be preserved when their plans, cadences, next charge dates and payment authorizations are recreated and validated correctly.

Can subscription data be migrated using CSV? Yes, for the subscription data itself — who is subscribed, to what, on what frequency, at what price and next charge date. A CSV describes the subscription records, not the payment credentials.

Are payment methods automatically transferred by a CSV? No. Raw card data and payment authorizations are never moved in a spreadsheet. Payment continuity is handled separately through the payment provider and Shopify’s contract-import tooling.

Do customers always need to resubscribe? No — not when the migration preserves their contracts and re-establishes a payment authorization. Whether a subscriber must take any action depends on the payment provider and the migration path.

What must be tested before migration? Recreated selling plans, a sample of imported contracts, next charge dates, discount accuracy, the payment path, and a test billing run — before the storefront experience is switched over.

Key takeaways

• Migrating Shopify subscriptions is officially supported and works in stages: first the settings (selling plans, selling plan groups, checkout discounts, delivery profiles and theme code), then the legacy subscribers themselves. (Shopify docs)
• Subscription data (customers, contracts, cadences, discounts, next charge dates) can move through a structured export such as a CSV. Payment credentials cannot — they are handled separately.
• Payment continuity depends on the source payment provider, not the export file. For Stripe, Braintree, Authorize.net and PayPal Express, the existing gateway can be connected as a legacy gateway to keep billing existing contracts. (Shopify docs)
• A subscription contract is detached from its selling plan once created, so plans, prices and discounts must be recreated accurately before contracts are imported. (Shopify docs)
• The biggest avoidable failure is double-billing. Shopify strongly recommends pausing billing in your current app while you migrate. (Shopify docs)
• Migration quality is a feature worth evaluating as carefully as price — a cheap app you cannot safely move to isn’t actually cheap.

What is Shopify subscription app migration?

Shopify subscription app migration is the process of moving active subscriptions from one subscription app to another so they continue billing without interruption. It involves recreating the plans, importing each subscriber’s subscription contract with the correct cadence, price and next charge date, and re-establishing a valid payment authorization — so existing subscribers keep receiving orders on their normal schedule rather than having to subscribe again.

What does Shopify subscription migration actually involve?

A subscription migration involves three distinct layers moving together: customer records, subscription data, and payment continuity. Shopify supports this in two official stages — migrating settings (selling plans, selling plan groups, checkout discounts, delivery profiles and theme code), then migrating the legacy subscribers themselves (payment methods, contracts and billing attempts). The subscription data travels through a structured file; the payment side is handled separately through the payment provider. Getting both right, in the right order, is the whole job.

What actually needs to migrate?

Not everything in a subscription app is equally fragile. The table below separates what each component contains from the risk it carries if it moves incorrectly.

The “Critical” rows are where migrations succeed or fail. A customer record that imports slightly wrong is an inconvenience; a contract that imports with the wrong next charge date, or without a valid payment method, is a lost or double-billed subscriber.

Shopify subscription payment migration explained

This is the most misunderstood — and most technically sensitive — part of the whole process, so it’s worth being precise. Several different things get lumped together as “payment migration,” and they don’t move the same way:

• Customer data — names, emails, addresses. Moves easily in an export file.
• Subscription data — the contract: variant, quantity, plan, cadence, next charge date. Moves in an export file.
• Payment methods — the billing authorization that lets the next charge run. Does not move in an export file.
• Payment tokens / credentials — the stored card relationship at the gateway. Never leaves the payment provider, and is never placed in a spreadsheet.
• Payment providers / gateways — the system that actually charges the card. This is what determines whether continuity is possible.

The key fact merchants miss: a CSV never moves payment credentials. Shopify deliberately built its tooling so you can “import pay-as-you-go contracts into Shopify without the need to migrate credit cards directly.” For certain gateways — Stripe, Braintree, Authorize.net and PayPal Express — the existing gateway can be connected as a legacy (secondary) payment gateway to keep billing the existing contracts, while new and updated contracts charge against Shopify Payments. Other gateways remain the same. (Shopify docs)

The practical implication: payment continuity depends on the source payment gateway and the migration architecture, not on the quality of your spreadsheet. When contracts are imported into Shopify (via subscriptionContractAtomicCreate), each one carries its variant, plan, payment method reference, and billing and shipping addresses. (Shopify docs) Whether a subscriber has to re-confirm anything comes down to whether that authorization can be re-associated — a payment-provider question to answer before you plan the cutover.

What is the cost of staying with an expensive subscription app?

Migration fear has a price, and it’s rarely on the invoice. The real cost of staying with an expensive subscription app is the sum of several things merchants tend to count separately, or not at all:

• Annual app cost — the subscription plan itself, which tends to creep upward.
• Transaction fees — a percentage skimmed off every recurring order, on top of the plan. (See how to avoid Shopify subscription transaction fees and how much Recharge actually costs.)
• Engineering dependency — the developer time spent maintaining a proprietary billing layer or working around it.
• Migration friction — the perceived difficulty of leaving, which is precisely what keeps prices sticky.
• Switching risk — the fear of dropping subscribers, which we’re addressing in this article.

Add those together and you get the total cost of staying. There’s no universal number being wasted — it depends entirely on your order volume and plan. But migration friction is frequently the largest line, and it’s the one that’s invisible on any statement. When you price your plan honestly, the friction is often the part quietly justifying everything else.

Thinking about switching? See how Curobi approaches supported subscription migrations.

How to migrate Shopify subscriptions safely

A safe migration is staged and verified, not a single overnight switch. The order below reflects Shopify’s own two-stage model — settings first, then subscribers — with the practical validation steps that keep subscribers from lapsing or doubling. For a condensed version of this process, see the step-by-step guide to switching subscription apps; the steps below go deeper on payment continuity and validation.

Step 1 — Audit the existing app

Before exporting anything, inventory what you actually have: how many active contracts, which selling plans and frequencies, which discounts and grandfathered rates, which payment gateway bills them, and which integrations depend on the app. This audit tells you where the risk concentrates.

Step 2 — Export your data

Export your customers, active subscriptions, cadences, discounts and next charge dates. Confirm your store is eligible for subscriptions (shop.features.eligibleForSubscriptions) before you plan the import. (Shopify docs)

Step 3 — Map the data

Map each field from the old app to the new one so nothing is silently dropped or misread. For example: Monthly → Monthly, 15% off → 15% off, next charge 2026-09-01 → 2026-09-01. This mapping is where mismatched discount rules and frequency labels get caught.

Step 4 — Recreate selling plans

Recreate your selling plans — frequency, pricing and discounts — in the new app before importing anyone. This matters because a subscription contract is detached from its selling plan once created: updating the plan later does not modify existing contracts. (Shopify docs) Get the plans right first, or every contract imported against them inherits the error.

Step 5 — Validate subscribers

Import the subscription contracts and validate them — variant, quantity, cadence, discount and status — against your export. Check a representative sample by hand, including any prepaid subscriptions and grandfathered-price customers, which behave differently from standard monthly plans.

Step 6 — Handle payment migration requirements

Resolve the payment path explicitly. Determine whether the source gateway can connect as a legacy payment gateway (Stripe, Braintree, Authorize.net and PayPal Express can), and how each payment authorization re-associates with the new contract. (Shopify docs) This is where “will customers have to re-enter a card?” is actually answered.

Step 7 — Test billing

Run a controlled billing test on a small number of contracts before the full cutover. Confirm the charge succeeds, the amount matches the plan and discount, and the next charge date advances correctly.

Step 8 — Prevent duplicate charges

Ensure only one billing schedule is live per contract. Pause billing on the old app before the new one begins charging — the detailed mechanics are in the section below, because this is the single most common migration failure.

Step 9 — Switch the storefront subscription experience

Move the customer-facing pieces over: the subscription widget on product pages (PDP), the customer portal (pause/skip/cancel), the checkout, and any storefront integrations. If the new app runs on Shopify’s native checkout, there’s no new checkout or redirect for customers to re-learn.

Step 10 — Monitor first renewals

Watch the first full renewal cycle closely. This is when a mis-imported next charge date, a broken payment authorization, or a dunning gap shows up — and it’s far cheaper to catch on day one than after a wave of failed charges.

Step 11 — Decommission the old app

Only after the new app has billed a full cycle cleanly and the data is validated should you cancel the old app. Keeping it dormant (not billing) during the overlap is your rollback safety net.

How to avoid duplicate charges during subscription migration

Double-billing is the failure merchants fear most, and it has one root cause: two live billing schedules charging the same contract at once. Shopify is explicit about this — it “strongly recommend[s] that you pause any billing in your current application while migrating customer payment methods and contracts … to avoid double-billing a contract.” (Shopify docs)

To avoid it:

• Understand why it happens. If the old app is still authorized to bill while the new app starts billing, a contract can be charged twice for the same period.
• Pause billing on the source app during cutover so only one schedule is ever live per contract.
• Test with a small set of subscriptions first and confirm a single, correct charge before scaling to the full base.
• Time the cutover around your billing cycle so you aren’t switching mid-charge for a large batch of contracts.
• Monitor the first renewals for duplicate or missed charges as soon as they run.
• Keep a rollback plan — the dormant old app — until the new app has completed a clean billing cycle.

Can you migrate from Recharge, Appstle, Loop, Bold, Seal or Skio?

Yes — the subscription data from all of these can be moved onto a native Shopify app, though the tooling and the payment-continuity picture differ by platform. Curobi’s own migration currently supports CSV-based migration from Recharge, Appstle, Loop, Bold or Seal. In every case, the payment-continuity caveat above applies: it depends on the source gateway.

Recharge → Curobi

Recharge subscription data — customers, active subscriptions, cadences, discounts and next charge dates — can be exported and imported. Because some Recharge setups have historically used their own checkout, confirm how payment authorizations transfer early. See the Recharge-to-Curobi migration path and the Recharge vs Curobi comparison.

Appstle → Curobi

Appstle runs on Shopify’s native Subscription Contracts, so contracts, selling plans and billing schedules generally export and recreate cleanly on another native app. See migrating from Appstle and Appstle vs Curobi.

Loop → Curobi

Loop subscriptions — subscribers, plans, frequencies and upcoming charge dates — can be exported and imported, with payment continuity depending on the underlying gateway. See migrating from Loop and Loop vs Curobi.

Bold → Curobi

Bold subscriptions can be exported and imported onto native Shopify Subscription Contracts. As always, validate contracts, next charge dates and the payment path after import. See migrating from Bold.

Seal → Curobi

Seal runs on native Subscription Contracts, so its subscription data recreates on another native app in the usual staged way. See migrating from Seal and Seal vs Curobi.

Skio → Curobi

Skio subscriptions can be moved onto native Shopify subscriptions, but Skio is not part of Curobi’s current CSV-migration list, so a move from Skio may require a manual or assisted path rather than the standard CSV import. Treat it as a case-by-case migration and confirm the approach before committing. For context on where the two differ, see Skio vs Curobi.

Migration comparison table

Not every component migrates the same way. Some travel reliably in the export; others always need verification after import. The table below separates the two so you know where to spend your validation time.

Shopify subscription migration checklist

Use this as a working checklist. It maps to the staged process above — settings and data first, cutover second, monitoring third.

Before migration

• Confirm the store is eligible for subscriptions (shop.features.eligibleForSubscriptions)
• Audit active contracts, plans, frequencies, discounts and grandfathered rates
• Identify the source payment gateway and whether it can connect as a legacy gateway
• Export customers, subscriptions, cadences, discounts and next charge dates
• Map every field old → new (e.g. Monthly → Monthly, 15% off → 15% off)
• Recreate all selling plans, prices and discounts in the new app first

During migration

• Pause billing in the current app before the new app begins charging
• Import subscription contracts against the recreated plans
• Validate a sample of contracts: variant, cadence, discount, status
• Verify next charge dates per contract
• Resolve and test the payment authorization for each gateway
• Run a controlled test billing on a small set of contracts

After migration

• Place the storefront widget, portal and checkout experience
• Reconnect and test integrations (email/SMS, loyalty, reviews, analytics)
• Monitor the first full renewal cycle for missed or duplicate charges
• Confirm dunning and failed-payment recovery are active
• Only decommission the old app after one clean billing cycle

Frequently asked questions

Can you switch Shopify subscription apps without losing subscribers?

In most cases, yes. Existing subscribers can be preserved when the migration recreates their selling plans accurately, imports each subscription contract with the correct cadence and next charge date, and re-establishes a valid payment authorization. Whether a subscriber has to take any action depends on the migration path and the payment provider involved. The safest migrations recreate the plans first, import contracts against them, verify every record, and only then move the storefront experience over — so subscriptions continue rather than restart.

Can you migrate Shopify subscriptions to another app?

Yes. Shopify officially supports migrating subscriptions onto its Subscriptions API in two stages: first the settings (selling plans, selling plan groups, checkout discounts, delivery profiles and theme code), then the legacy subscribers themselves — payment methods, subscription contracts and billing attempts. Any app built on Shopify’s native Subscription Contracts can receive migrated subscriptions, though the exact tooling and level of automation differ between apps.

Can you migrate from Recharge to another subscription app?

Yes. Recharge subscription data can be exported and imported into another Shopify subscription app. The customers, active subscriptions, cadences, discounts and next charge dates are typically carried in an export file, while payment continuity depends on the gateway those subscriptions were billed through. Because Recharge has historically used its own checkout on some setups, it is worth confirming how payment authorizations transfer before you plan the cutover.

Can you migrate from Appstle to another subscription app?

Yes. Appstle runs on Shopify’s native Subscription Contracts, so the subscription records, selling plans and billing schedules can generally be exported and recreated in another native app. As with any migration, the customer and subscription data usually moves through a structured file, while the payment method and next charge date should be validated after import rather than assumed.

Can you migrate from Loop to another subscription app?

Yes. Loop subscriptions can be exported and imported into another Shopify subscription app that supports migration. The subscriber list, plans, frequencies and upcoming charge dates travel in the export, and the payment-method continuity depends on the underlying gateway and how the new app re-associates each authorization. Validate a sample of contracts after import before you decommission Loop.

Can payment methods be migrated between subscription apps?

Sometimes, and it is the most technically sensitive part of any migration. Raw card numbers are never moved in a spreadsheet. Shopify built tooling to import pay-as-you-go contracts without migrating credit cards directly, and for certain gateways — Stripe, Braintree, Authorize.net and PayPal Express — the existing gateway can connect as a legacy payment gateway to keep billing existing contracts. Whether a payment method carries over therefore depends on the source payment provider and the migration architecture, not on the export file itself.

Can you migrate Shopify subscriptions using a CSV file?

A CSV is commonly used to move customer and subscription data — who is subscribed, to which variant, on what frequency, at what price and with what next charge date. A CSV does not move payment credentials. Card data and payment authorizations are handled separately through the payment provider and Shopify’s contract-import tooling. So a CSV is an accurate way to describe the subscription-data portion of a migration, but not the payment-continuity portion.

Will customers have to re-enter their payment information after migration?

It depends on the payment provider and the migration path. Where the source gateway can be connected as a legacy payment gateway or the payment method can be re-associated with the new contract, existing subscribers may not need to act at all. Where a subscription was billed through a provider or checkout that cannot transfer its authorization, some subscribers may need to re-confirm or update their payment method. This is exactly why the payment path should be resolved before the cutover, not after.

How long does a Shopify subscription migration take?

It varies. The main drivers are the number of active subscribers, how complex the selling plans and discounts are, and which payment gateway the subscriptions were billed through. A small store on a single plan with a straightforward gateway is a very different exercise from a large store with grandfathered pricing, multiple frequencies and prepaid contracts. Rather than promise a fixed timeline, plan the migration in stages — settings first, then data, then storefront — and validate at each step.

How do you prevent duplicate charges during a subscription migration?

The main risk is running two live billing schedules at once — the old app and the new one both charging the same contract. Shopify strongly recommends pausing billing in your current application while you migrate payment methods and contracts, to avoid double-billing. Practically, that means pausing charges on the source app during cutover, testing with a small number of subscriptions first, monitoring the first renewals closely, and keeping a rollback plan until the new app has billed a full cycle cleanly.

What happens to discounts and grandfathered pricing during migration?

Discounts and legacy pricing have to be recreated deliberately, because a subscription contract is detached from its selling plan once created — updating a plan later does not change existing contracts. That means the discounted and grandfathered rates loyal subscribers are on must be reproduced on the new plans before contracts are imported against them, and then verified. Grandfathered pricing is one of the highest-risk items in a migration precisely because it cannot always be reconstructed if the source record is lost.

What happens to next billing dates when subscriptions are migrated?

Next charge dates are one of the most important fields to preserve, and they carry in the subscription data rather than the payment data. Each imported contract should keep the same next billing date it had on the old app, so the customer is charged on their normal schedule rather than early or twice. Because contracts are imported individually with their own billing schedule, the next charge date should be validated per contract after import — not assumed to be correct because the plan looks right.

Where Curobi fits

If the only thing keeping you on an expensive subscription app is the fear of moving, that fear is worth pricing out — and it’s a smaller obstacle than it looks once the payment path is understood.

Curobi provides CSV-based migration from Recharge, Appstle, Loop, Bold or Seal, designed to preserve active subscriptions rather than restart them. It’s included on the Pro plan at no extra onboarding cost, not a paid add-on. Because Curobi runs on Shopify’s native checkout and Subscription Contracts, there’s no proprietary billing layer to rebuild around — and your reviews, loyalty, email/SMS and analytics apps keep seeing subscription orders as ordinary native Shopify orders, which matters for keeping churn and reporting intact through the move.

Who should consider it: merchants on a fee-heavy or proprietary-checkout app who want to move onto native rails without dropping subscribers — coffee roasters and other replenishment brands with grandfathered pricing and month-to-month cadences included.

What you provide: an export of your active subscriptions — customers, plans, cadences, discounts and next charge dates — plus your source gateway details so the payment path can be confirmed.

What happens next: plans are recreated and validated, contracts are imported and checked, the payment path is resolved (subject to Shopify and payment-provider requirements), and the storefront experience is switched once the data is verified — with the old app kept dormant as a rollback until the first clean billing cycle completes.

See how Curobi approaches migration, read the condensed step-by-step guide, or check the pricing and FAQ to weigh the full cost of staying against the cost of moving. If your reason for staying is churn rather than fees, the guide to reducing subscription churn is the better starting point.