Why merchants migrate away from Recharge, Loop, and Skio
The three most common reasons merchants migrate — often in combination — are cost, portal quality, and feature gaps. Understanding which one is your primary driver shapes what a successful migration looks like for your store.
- Transaction fees: Recharge's standard tier charges 1.25–1.99% per transaction on top of Shopify Payments processing. At $50,000 MRR, that's $7,500–$12,000 per year in fees that disappear when you move to a flat-rate app.
- Portal UX: the customer portal is the primary self-service interface for your subscribers. When the portal is slow, confusing, or mobile-unfriendly, support ticket volume rises and churn follows. Merchants moving for portal reasons typically have support data showing 20%+ of tickets are 'how do I pause/skip/swap'.
- Missing features: specific capabilities like build-a-box, prepaid plan management, cohort analytics, or custom billing schedules are often absent in legacy apps. These gaps become visible as the subscription program matures and merchants want to operate more sophisticatedly.
What actually needs to migrate: the complete data inventory
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 a migration timeline, verify your migration partner has explicit plans for each item.
- Subscription contracts: each active subscription's product line items, quantities, variants, and subscription plan ID. These must 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 stores payment credentials in its native vault, accessible via customer payment method IDs. Properly migrated subscriptions use the same token — subscribers are never asked to re-enter card details.
- Discount and promotional pricing: subscribers on legacy discount rates, founding member pricing, or promotional tiers must maintain those prices post-migration. Check every unique price point in your subscriber base.
- Shipping address and delivery preferences: straightforward to migrate but frequently omitted from 'lightweight' migrations that focus only on billing.
- Subscription status: active, paused, and cancelled-with-remaining-prepaid-cycles all need distinct handling.
The staging dry-run: the step most migrations skip
A production migration without a staging dry-run is a gamble. The dry-run is the step that turns a stressful migration into a boring one. It exposes data mapping failures, billing date edge cases, and product variant mismatches before they affect real subscribers. Insist on this step regardless of how straightforward your data looks.
- Clone your Shopify store to a development environment and install the destination app. Run the full migration import against the clone.
- Verify a random sample of 50–100 contracts across different subscription types, billing dates, and discount tiers. Check that every field transferred correctly, not just the most common cases.
- Run a test billing cycle in the staging environment to confirm that payment method tokens are valid and charges process correctly.
- Check that the selling plan structure in the destination app produces the correct pricing for every discount tier your subscribers are on.
- Document any exceptions found and resolve them in the data mapping before scheduling the production cutover.
Planning the cutover: timing, communication, and rollback
The cutover — switching from old app to new app in production — is the moment of highest risk. Proper planning compresses that risk window to minutes rather than hours and ensures that any problem discovered post-cutover can be reversed without subscriber impact.
- Schedule the cutover during the lowest-traffic period in your billing calendar: typically 2–3 days after your largest billing cluster, not just before it. This maximizes the time before the first real billing event occurs in the new app.
- Prepare a communication template for subscribers that explains the portal has been updated, where to find it, and who to contact with questions. Send it the day after cutover, not before — pre-announcing migration can trigger preemptive cancellations.
- Keep the old app installed but paused for 30 days post-cutover. Do not uninstall it immediately. This preserves the ability to reference historical contract data and provides a rollback path.
- Define explicit rollback triggers before cutover: if more than X% of next-day billing fails, or if support ticket volume spikes above Y, you roll back. Having the criteria defined in advance prevents hesitation when the decision needs to be made quickly.
What to expect in the first 30 days after migration
Even a clean migration produces a temporary increase 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.
- Expect a 20–40% increase in portal-related support contacts in the first 2 weeks as subscribers encounter the new interface. This normalizes by week 3.
- First billing cycle post-migration 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 period.
- Some subscribers will notice the new portal design and contact support to ask what changed. Prepare a one-paragraph explanation: 'We've upgraded our subscription management system. Your subscription, billing date, and pricing are unchanged.'
- Track cancellation rate by weekly cohort for the first 60 days post-migration. A clean migration should show no statistically significant increase in cancellations. If you do see a spike, segment by subscription type, billing tier, and next-billing-date to identify the root cause.