Migrating Shopify subscriptions from Recharge, Loop, Skio, Appstle, Bold, or Seal — zero downtime

Which platforms we migrate from — and how each one works

We migrate active subscription contracts from every major Shopify subscription app, plus generic CSV and a public REST API for anything else. Most migrations are one-click and finish in under 30 minutes; the rest take an hour of merchant attention split between audit, staging review, and customer comms. The exact method per source is below — every path lands in a staged review first, so nothing goes live until you approve it.

• Appstle Subscriptions — one-click via Shopify-native contracts. No API key required. Bypasses Appstle's Enterprise tier-lock on their own REST API. Click "Detect & Import" on the Appstle card in the migration page.
• Bold Subscriptions V2 — one-click via Shopify-native contracts. Same flow as Appstle. Bold V1 (which billed through Bold's own ledger, not Shopify) takes the CSV path instead.
• Seal Subscriptions — REST API import. Paste your Seal merchant API token (Seal admin → Settings → API). We page through every subscription via Seal's /subscriptions endpoint with full schema parity (status, intervals, line items, addresses).
• Skio — GraphQL API import. Paste your Skio API token (Skio admin → Settings → API → Generate). Full subscription contracts, billing schedules, line items, and storefront-user metadata.
• Loop Subscriptions — REST API import OR CSV export. API key from Loop → Settings → API. Contracts, customer data, billing schedules.
• Recharge — REST API import OR CSV export. API token from Recharge → Settings → API tokens. Subscriptions, payment methods, selling plans.
• Anything else (Bold V1, legacy apps, custom apps) — CSV import. Download our template, fill it in from your current app's admin export, upload. Per-row validation and error reporting.
• Custom integrations or ongoing sync — Public REST API. Generate an API key in the migration page, POST contracts programmatically. Useful for migrating from outside Shopify (Stripe, WooCommerce) or for ongoing data sync.

All migrations are free — we don't charge per contract, per migrator hour, or as a percentage of moved MRR (some incumbent apps still do). The migration page lives at /app/migration inside the embedded admin app once you install SimpleSubscription. Detailed per-platform considerations (data quirks, schema gotchas, communication scripts) are in the sections that follow.

Why merchants migrate — and which reason shapes the migration plan

Merchants leave their subscription app for one of four reasons, usually in combination: cost (transaction fees compound brutally as MRR scales), portal quality (a slow or confusing portal drives both support tickets and cancellations), missing features (build-a-box, custom billing schedules, cohort analytics, prepaid plans), and support response time (when a billing bug takes 5 days to triage and your renewals are running, that's existential). Knowing which reason is your primary driver shapes what a successful migration looks like for your store.

If cost is the primary driver, the migration math is concrete. A subscription business at $50,000 MRR on Recharge's standard plan pays roughly $7,500–12,000/year in transaction fees alone, on top of Shopify's processing fees and the monthly app subscription. Loop and Skio sit in similar territory at scale (Loop ~1%, Skio ~1% + 20¢ per transaction). A flat-fee app at $79–299/mo crosses below those costs at around $8,000 MRR and the gap widens linearly above it. Migration ROI compounds every month you stay on the flat-fee side, so the calendar math matters — a migration that pays back in 4 months is a 3x annualized return.

If portal quality is the driver, the migration plan needs to weight subscriber-facing UX (cancellation flow, pause, skip, swap) ahead of admin niceties. If missing features is the driver, validate that the destination app actually has the feature you need at the depth you need — "supports build-a-box" can mean a fully fledged drag-and-drop builder or a basic 2-tier picker. If support response time is the driver, ask for live references from existing customers at your store's MRR tier before committing.

The complete data inventory — what actually has to migrate

A migration checklist that misses any of the following fields results in either failed charges, incorrect billing dates, or subscribers who have to re-enter their payment details — all of which drive cancellations. Before agreeing to any migration timeline, verify your migration partner has explicit plans for each of these. Missing any of them is a sign the migration plan is too lightweight.

• Subscription contracts — each active subscription's product line items, quantities, variants, and subscription plan ID. Map to corresponding selling plan groups in the destination app.
• Next billing date — the single most important field. A subscriber expecting to be billed on the 15th who gets charged on the 1st will dispute the charge. Dates must be preserved to the day.
• Payment method tokens — Shopify vaults card credentials natively (accessible via customer payment method IDs). A clean migration uses the same Shopify-side token so subscribers are never asked to re-enter card details. Some legacy apps stored tokens with the payment processor instead — see the Bold/Ordersify section below.
• Discount and promotional pricing — subscribers on legacy discount rates, founding-member pricing, or promotional tiers must keep those prices post-migration. Check every unique price point in your subscriber base, not just the headline subscription discount.
• Shipping address and delivery preferences — straightforward to migrate but frequently omitted from "lightweight" migrations that focus only on billing data.
• Subscription status — active, paused, cancelled-with-remaining-prepaid-cycles, and trial all need distinct handling. Paused subscriptions especially — they have to land paused on the new side, not active.
• Customer-side metadata — cancellation reasons, save-flow history, last-shipment delivery confirmations. Nice to have, not strictly required for billing continuity, but useful for retention analytics post-cutover.

The two migration paths: CSV export vs API

There are two viable approaches to a subscription migration, and the right choice depends on what your source app actually exposes. Some apps offer both; some only offer one; some offer a CSV that's missing critical fields. Verify before you commit.

CSV export — the source app generates a flat file (one row per subscription) and the destination app imports it. Simpler operationally, slower iteration cycle (export, fix, re-export), and the export schema often misses fields the destination needs. Works fine if the source is straightforward (e.g. all subscribers on one selling plan, no exotic prepaid configurations) and the export includes payment tokens or token references. Doesn't work for migrations with thousands of variant-level customizations.

API migration — direct programmatic access to the source app's data via its REST or GraphQL API. Faster iteration (you can re-run for delta updates), supports complex contracts with nested data, and lets the migration tool reason about edge cases (paused subscriptions, partial prepaid balances, mid-cycle discount changes). Requires API credentials from the source app, which not all platforms grant willingly — some apps restrict their API to their own customers for fear of migration tooling. Recharge and Skio both offer reasonable API access; Loop's API is partner-only; Bold's older apps have weak or no API. Workarounds exist (the source app's admin UI can usually generate the export, and the migration tool then processes the file as if it were a CSV).

• CSV — fast to start, brittle on complex data, fine for <500 subscribers with simple structures
• API — slower setup (credential exchange, schema discovery), much more reliable on complex data, supports delta sync for staged migrations
• Hybrid — full data via API, plus a CSV of any edge cases (legacy discount tiers, custom metadata) hand-mapped at the end

The pre-migration audit — what to do BEFORE moving anything

The pre-migration audit is the step most migrations skip and most migrations regret. It's the step where you discover that 4% of your subscribers have a billing date that doesn't match the cadence (because someone manually rescheduled them three years ago), or that you have 28 different unique price points in your subscriber base (because legacy promotions were never cleaned up), or that 12 subscribers are in a payment-failure state that's been silently retrying for months.

Run this audit at least a week before cutover, and ideally two. Fix what you can fix in the source app before migrating — it's much easier to clean up a stale discount tier in your current platform than to translate it into the new one. The fewer edge cases you carry across, the cleaner the migration runs.

1. List every unique price point in your subscriber base. Match each to a known discount tier. Investigate any anomalies (single subscribers at one-off prices are usually legacy hand-edits).
2. Identify subscriptions in payment-failure state. These won't migrate cleanly — decide upfront whether to attempt recovery before cutover, migrate them as-is into the new app's dunning flow, or cancel them with a courtesy email.
3. Identify upcoming renewals in the migration window. Anything renewing within 48 hours of cutover should be paused or processed in the old app first. Mid-flight renewals are the #1 source of post-migration billing chaos.
4. Audit selling plan configuration on the source side. Document every selling plan, cadence, discount, and the products attached. The destination app needs equivalent structures created BEFORE the migration runs.
5. Run a paused-subscription census. Paused subs frequently get treated as cancelled by lazy migration scripts. Make sure each one transfers in its paused state with the correct resume-date intact.
6. Decide your discount-history policy. Do you preserve every subscriber's historical promotional rate forever, or do you reset everyone to the current published discount? This is a strategic call — preserving history is friendlier to subscribers; resetting can recover meaningful margin.

Migrating from Recharge — the specific gotchas

Recharge is the oldest of the major Shopify subscription apps and has the most legacy structure. A clean migration from Recharge is achievable but the surface area is larger than from newer apps. The key gotchas:

• Legacy contracts predating Shopify's native subscription API — Recharge used to bill via its own ledger; later contracts use Shopify's native subscription contracts. Some merchants have both vintages in their subscriber base. Migration tooling has to detect which is which and handle them differently.
• Recharge Custom Workflows — merchants frequently build custom logic in Recharge (auto-tag subscribers at certain milestones, conditional discount application, custom email triggers). None of this is portable. Inventory your workflows and decide what to rebuild on the destination side before cutover.
• Recharge bundles vs Shopify selling plan groups — Recharge's bundle and pack constructs don't map 1:1 to Shopify selling plans. If you sell bundles, the destination needs explicit bundle support and the migration has to translate the Recharge structure into the equivalent.
• Payment-method handling — Recharge mostly uses Shopify-vaulted tokens for newer contracts. Some older contracts may have payment methods stored Recharge-side. Audit before migrating.
• Migration cost historically — Recharge has historically charged $500+ for migration assistance when subscribers move TO them. Some apps reciprocate by charging similar fees to migrate FROM Recharge. We don't — our migration from Recharge is free, regardless of subscriber count. See why our pricing is structured this way.

Migrating from Loop — what transfers cleanly, what doesn't

Loop is newer than Recharge and built on Shopify's native subscription contracts API from the start. That makes the technical migration cleaner — contracts, payment tokens, and selling plan structure all map well. But Loop's portal customizations and analytics-side data are where the friction lives.

• Subscription contracts — transfer cleanly. Native Shopify structure on both sides.
• Payment methods — Shopify-vaulted tokens transfer with the contract.
• Portal customizations and branding — Loop's portal builder doesn't export. The destination's portal will look different by default; plan to rebuild the branding (logo, colors, custom modules) before subscribers see the new portal.
• Cohort analytics and historical metrics — historical MRR, churn curves, and cohort retention data stay in Loop's analytics dashboard. You can't migrate the historical data; you can only start fresh on the destination side. Export historical analytics as CSVs and archive separately if you need them for board reporting.
• Loop's API access — partner-tier only. Most merchants will migrate via CSV export from Loop's admin UI, processed by the destination app's migration tool.
• Box subscriptions — Loop has decent box-building. If you use it, validate that the destination app's box builder supports the same configuration depth before migrating, otherwise subscriber-level customizations may be lost.

Migrating from Skio — API access and contract structure differences

Skio is the newest of the four and has the most modern API (GraphQL, well-documented), which makes the technical migration the smoothest of the bunch on paper. The reasons merchants leave Skio are usually cost (1% + 20¢ per transaction stacks fast) or feature depth on edge cases (analytics, build-a-box capability), not technical migration difficulty.

• GraphQL API — well-documented, fully featured for migration use. The destination app's migration tool can pull everything programmatically.
• Subscription contracts — native Shopify structure, transfer cleanly.
• Skio-specific incentives and promotions — Skio has powerful promotion logic (referral codes, first-order discounts, loyalty integration). Most of this doesn't translate 1:1 to other apps; document the rules and rebuild equivalents on the destination side.
• Loyalty integrations — Skio integrates with Yotpo, LoyaltyLion, and others natively. If you use a loyalty app, verify destination compatibility before migrating; otherwise loyalty point accruals on subscription orders may break.
• Subscriber-facing portal — Skio's portal is well-regarded. Subscribers will notice the change in look-and-feel. Brief your support team on the difference and prepare a post-migration FAQ.

Migrating from Appstle — Shopify-native contracts and the Enterprise API tier

Appstle is one of the most-installed subscription apps on Shopify, with strong build-a-box, membership, and bundle features. It stores subscriptions as Shopify-native subscription contracts, which makes the technical migration straightforward — the destination app can read every contract directly from Shopify Admin GraphQL without ever needing an Appstle API key. Most merchants migrating off Appstle do so because of pricing tier creep (advanced features and API access are gated behind Enterprise pricing at $100+/month) or portal usability friction at scale.

• Shopify-native contracts — every Appstle subscription lives as a standard SubscriptionContract in Shopify. A modern destination app reads them via the subscriptionContracts GraphQL query using the merchant's existing Shopify session — no Appstle API key required, no Enterprise-tier dependency.
• App attribution — contracts created by Appstle are tagged with app.title = "Appstle Subscriptions" on the Shopify side, so a destination importer can filter precisely and skip contracts created by other apps in mixed-vendor stores.
• API access tier-locked — Appstle's own REST API at subscription-admin.appstle.com is documented but gated behind their Enterprise plan. Avoid migration tools that require it; the Shopify-native path is faster and free.
• Build-a-box configurations — Appstle's build-a-box UI stores box-level metadata in app-specific metafields. Verify destination support for re-importing these or be prepared to reconstruct them in the destination admin.
• Membership/loyalty rules — Appstle Memberships is a separate product. If you use it, plan its migration independently of the subscriptions migration.

Migrating from Seal Subscriptions — clean REST API and full schema parity

Seal Subscriptions is one of the easier sources to migrate from because it offers a well-documented public REST Merchant API with the same status enums (ACTIVE, PAUSED, CANCELLED, EXPIRED) and billing-interval semantics that most modern subscription apps use. Seal stores its own copy of every subscription in its database but links each one to the Shopify-native contract via the shopify_graphql_subscription_contract_id field — so destination apps have two clean import paths to choose from.

• Merchant REST API — base URL app.sealsubscriptions.com/shopify/merchant/api, authentication via X-Seal-Token header. The /subscriptions endpoint paginates 50 per page with filters for active-only, paused-only, cancelled-only, with-items, and with-billing-attempts. No tier lock — API access is included on all plans.
• Rate limit — 10 concurrent requests per API key. Migration importers should serialize page fetches rather than parallelise them; you'll hit HTTP 503 (not 429) if you over-saturate.
• Schema parity — status enums, line item fields (product_id, variant_id, final_price, quantity), shipping address fields (s_first_name ... s_country_code), and selling-plan IDs all map cleanly to the destination's native fields. Less translation work than Recharge or Loop.
• Next billing date — not exposed as a direct field on the subscription. Derive it from the first uncompleted entry in billing_attempts[], where completed_at is empty.
• Discount codes & loyalty — Seal exposes discount_codes per line item. If you use Shopify's native discount engine on subscriptions, these transfer cleanly. Build-a-box bundles via Seal's bundle feature need verification on the destination side.

Migrating from Bold, Ordersify, or other older platforms

Bold Subscriptions and Ordersify are the oldest of the apps in active use, and the data quality varies dramatically by merchant. Some merchants on these platforms have clean data and a straightforward migration; others have years of accumulated legacy state (manual contracts edited in support tickets, deprecated billing schedules, customer payment methods stored with the gateway instead of Shopify-side). The audit is more important here than for any other source.

• Pre-Shopify-API contracts — Bold's older versions billed through Bold's own ledger, not Shopify's native subscription contracts API. Migration involves not just moving data but recreating the contracts as Shopify-native entities. This is the biggest reason Bold migrations take longer than newer-platform migrations.
• Payment-method tokens — some Bold contracts have payment methods vaulted with the payment processor (Authorize.net, Stripe-direct) rather than Shopify. These require subscriber outreach — there's no way to silently re-vault the card without subscriber action. Plan a card-update email campaign as part of cutover for affected subscribers.
• API access — limited or unavailable on older Bold versions. Most Bold migrations are CSV-based via admin export.
• Data quality — verify every billing date, every price, every subscriber status. Bold customers frequently discover during the audit that they have 50+ "active" subscriptions in the database that haven't actually billed in 18 months — silent data rot.
• Cutover communication — subscribers on Bold often have less context for what the subscription app even is. A migration confirmation email should explain in plain language that nothing changes about their subscription except the portal address.

Note on Ordersify: Ordersify is a suite of Shopify order-automation apps (PDF invoices, pick-pack-fulfill, restock alerts, order exporter, automation tags) — not a subscription billing platform. If you arrived here looking to migrate "away from Ordersify," you're likely looking for a different operations app, not a subscription app. No subscription contract data needs to move.

Customer communication during migration — do you tell them?

Most successful migrations communicate sparingly and at the right moment. The biggest mistake new operators make is pre-announcing the migration weeks in advance, which serves no purpose except to remind subscribers that they have a subscription they could cancel. Subscribers do not need to know about the migration before it happens; they need to know what changed if and when they encounter the new portal.

The right communication pattern: zero pre-announcement, a one-time confirmation email the day after cutover, and a polished post-migration FAQ at a stable URL that support can link to. Frame the change as an upgrade — "we've upgraded our subscription management system; your subscription, billing date, and pricing are unchanged" — and avoid framing it as a platform switch (which raises subscribers' anxiety about the platform they originally trusted).

• Day -1 (pre-cutover): nothing. Don't email subscribers.
• Day 0 (cutover): nothing public. Internal channels brief support and ops.
• Day +1 (day after cutover): one-time confirmation email — "we've upgraded the system; everything is unchanged; here's the new portal URL."
• Day +2 to +30: post-migration FAQ live on your help center; support team trained on common questions.
• Exception: subscribers requiring action (e.g. Bold subscribers who need to re-enter cards) get a separate, more prominent campaign with one-click re-vault. Don't bury action items in the general announcement.

Verifying the migration — the first 30 days post-cutover

Even a clean migration produces a temporary uptick in subscriber contact and a small number of edge-case issues in the first 30 days. Planning for this avoids interpreting normal migration noise as a product failure. The right metrics to watch are billing success rate, support ticket volume, and weekly cohort cancellation rate — segmented finely enough to spot anomalies.

1. Renewal day 1 monitoring. The first billing cycle after cutover is the true test. Review every billing result the day charges run. Failed charges that would have been routine retries in the old app may need manual intervention during the transition.
2. Payment success rate. Should be within 1-2 percentage points of pre-migration baseline. A larger drop means payment tokens didn't transfer cleanly for some segment — investigate immediately.
3. Support ticket volume. Expect a 20-40% increase in portal-related contacts in weeks 1-2 as subscribers encounter the new interface. Normalizes by week 3. A 100%+ increase or volume that doesn't normalize is a signal that the portal UX has a real problem for your subscriber base.
4. Weekly cohort cancellation rate. Compare each post-migration week's cohort to the pre-migration trailing 8-week average. A statistically significant uptick is the warning sign. Segment by subscription type, discount tier, and original signup date to localize the cause.
5. Chargeback rate. Should be unchanged. A chargeback spike post-migration is almost always a payment-token issue or a billing-date mismatch — investigate the specific transactions and reconcile.

Keep the old app installed (paused, not uninstalled) for at least 30 days post-cutover. This preserves the ability to reference historical contract data if a discrepancy comes up, and provides a documented rollback path if a serious issue emerges. The cost of leaving an unused app installed is zero; the cost of needing it after uninstall is significant.

What goes wrong — and how to handle each failure mode

Even with rigorous preparation, some things go wrong during real-world migrations. The point of this section is not to scare you off but to give you the playbook for each common failure mode so you can react in minutes, not hours.

• Payment-method tokens didn't transfer for a subset of subscribers — typically a small percentage with gateway-side vaulted cards. Identify the cohort immediately, send a one-click re-vault email, follow up with phone outreach for high-value accounts. Expect 60-75% recovery.
• Billing dates shifted by a few days — usually a timezone or date-format bug in the migration tool. Pause renewals immediately, reconcile the dates manually (or via a script), notify any subscriber whose date moved more than 2 days.
• Discount tiers reset to defaults — subscribers on legacy discounts suddenly see the standard rate. This is the worst kind of bug because it doesn't surface until renewal day. Audit before cutover; if it happens post-cutover, halt all billing, restore the discount mapping, and re-issue any incorrect charges with a courtesy email.
• Paused subscriptions came across as active — they'll bill on the next cycle and ship product the subscriber didn't expect. Identify the cohort, pause them again, refund any incorrectly-shipped orders.
• Support volume spike beyond expectations — usually a portal UX issue (cancel link harder to find, swap flow confusing). Triage the top 3 ticket categories, fix UX bugs first, deploy FAQ updates for the rest.
• Subscriber confusion about the new portal URL — solved by setting up a redirect from the old portal address (if technically possible) and by including the new URL prominently in confirmation emails and shipping notifications.

Why our migration is free — and why others charge

Historically, the major Shopify subscription apps have charged for migration assistance — Recharge has charged $500+ for incoming migrations in the past, and several other apps have followed similar models, sometimes with higher fees scaled to subscriber count. The economic logic from their side is straightforward: migration is real engineering work, the subscriber acquisition cost is high in this category, and a paid migration filters for serious commitment.

We don't charge for migration, and the reasoning is the inverse of that logic. We compete on transparent flat-fee pricing — no transaction fees, no per-subscriber overage, no annual contract uplift. The merchants who benefit most from that pricing structure are also the ones for whom a $500 upfront migration fee is the biggest deterrent. By making migration free, the math becomes simple: move to a flat-fee platform, save the variable transaction fees, and pay back the migration cost in the first month or two regardless of subscriber count. There's no gotcha and there's no upsell tier where the migration would have been chargeable; our pricing is structured around flat fees and free migration as the headline differentiators.

Practically: we run the audit, we operate the migration tool, we stage the data in a preview environment, we run the cutover, and we monitor renewal day 1 with you. If you're on Recharge, Loop, Skio, Bold, Ordersify, or any other Shopify subscription app — the migration itself doesn't cost anything. The only thing we ask is that you give the audit phase the time it deserves; a rushed migration costs more than a paid one in cancelled subscribers.