For brands with meaningful subscription revenue ($1M+ annual recurring), subscription continuity is the highest-stakes piece of the migration. The technical work is straightforward; the operational discipline around cutover sequencing is where outcomes are determined.
This page is the operator playbook: how to sequence the cutover, what comms to send, how to prevent double-billing, and how to manage the inevitable edge cases without losing subscribers.
Symptoms
How the problem surfaces
Customers get charged twice in the same billing cycle
The most painful and most common subscription migration failure. Customer pays on source platform on day X, then again on Shopify on day X+1 or X+7 because the cutover sequencing did not coordinate billing. Triggers immediate refund requests and chargebacks.
Subscription cycles drift after migration
Customer was on a 30-day cycle on the source platform; after migration the next bill date is 35 or 25 days later because the cycle reset rather than carried forward. Triggers customer confusion and support tickets.
Subscribers churn during the cutover window
Customers who get confused by the cutover (new login flow, different product names, changed billing dates) often cancel rather than work through the friction. Brands without proactive subscription comms see meaningfully higher churn during the cutover window than during normal operations.
Stripe or payment-processor errors at cutover
Payment-processor tokens often need to be reissued at cutover because the customer-of-record relationship is changing platforms. Brands that do not coordinate with the payment processor in advance see authorisation failures at the first post-migration billing cycle.
Solution
The operator playbook
Sequence the cutover around the billing cycle
The single most important discipline: choose a cutover date that aligns with the lowest-volume billing window for the active subscriber base. For most brands this means cutting over between billing cycles rather than during one. Map the billing-cycle distribution before scoping the cutover; pick the date where the fewest active billings are in flight.
For brands with a single dominant billing cycle (most subscriptions on the 1st or 15th of the month), the cutover should happen in the days immediately after the cycle completes. This gives the maximum runway before the next billing event surfaces in the Shopify subscription app.
Define a hard "stop charging on source, start charging on target" date
The cutover runbook must include a specific date on which the source platform stops processing subscription billing and the Shopify subscription app starts. This date is the contract for the engineering team and the comms for the customer. Brands without this explicit date consistently produce double-billing scenarios where both platforms process the same cycle.
The mechanic: on the cutover date, disable subscription billing on the source platform first, validate the disable, then enable on Shopify. The order matters; reversing it produces an overlap window where both systems are charging.
Coordinate with the payment processor in advance
Stripe, Braintree, or whichever processor the brand uses needs to know about the migration in advance because customer-of-record tokens often change. The payment-processor relationship manager (every $5M+ brand has one) should be looped into the cutover runbook two to four weeks before launch.
The output of the coordination is a clear plan for how subscriber payment methods carry forward: which tokens migrate, which need to be re-authorised, and how to handle the customers whose payment methods cannot transfer cleanly. Brands that skip this coordination see authorisation failures at the first post-migration cycle.
Send proactive subscriber comms before the cutover
Active subscribers should receive an email 7-14 days before the cutover explaining the upcoming change, the new login flow, and what to expect on their next billing date. The email should be designed to reduce surprise and friction, not to upsell or promote.
For brands with high-value subscribers (anyone over a few hundred dollars annual recurring), consider a follow-up email at cutover day confirming the change and providing direct support contact for any issues. The personal touch retains the highest-value subscriber segment through the cutover friction.
Monitor first-cycle billing carefully
The first post-migration billing cycle is the make-or-break event. Monitor authorisation failures, duplicate charges, and subscriber-initiated cancellations in real time during the first cycle. Brands that staff a dedicated subscription-cutover monitor for the first week catch issues fast enough to resolve them before they compound; brands that monitor casually consistently let small issues become customer-facing incidents.
Cost
Cost range: $15K-$70K (inside the broader replatforming engagement)
| Cost line | Range |
|---|---|
| Subscription migration agency engineering hours | $10K-$40K |
| Vendor-managed migration tier (Recharge/Skio if used) | $3K-$15K |
| Payment processor coordination work | $1K-$5K |
| Subscriber comms design and send | $1K-$5K |
| First-cycle monitoring and incident response | $0-$5K |
Dominant cost is engineering hours on the customer-data and billing-state reconciliation, plus the optional vendor-managed migration tier for brands with substantial active subscriber bases. The cost scales roughly with active subscriber count and billing-cycle complexity.
Timeline
Timeline: 6-10 weeks (parallel to broader replatforming)
Discovery
Weeks 1-2
Subscriber base analysis, billing-cycle distribution mapping, payment-processor coordination kickoff
Migration build
Weeks 2-6
Subscription data migration, target app configuration, payment-token handling
Cutover prep
Weeks 5-7
Subscriber comms send, dry run on cutover sequencing, monitoring setup
Cutover
Week 7-8
Source-stop, target-start, first-cycle monitoring
Stabilisation
Weeks 8-12
Cycle 1 and 2 monitoring, subscriber follow-up, edge-case resolution