When you migrate a WooCommerce store, subscriptions are the hardest piece to move, because a subscription is not just a record on your site: the recurring billing is anchored to a payment token held by your payment gateway, and that token is what actually charges the customer on schedule. So migrating the subscription record alone is not enough; the billing relationship at the gateway has to come with it, or renewals fail and customers lapse. The safest path is to keep the same payment gateway account and migrate the subscription and its stored payment token together, coordinating with the gateway where needed, so billing dates and amounts carry over and no one is double-billed or dropped. Switching gateways at the same time makes this much harder and should be avoided unless you plan it deliberately. Because this touches live money, it is tested carefully before launch. WPBuildAI plans the subscription move around your gateway, preserves billing schedules and amounts, and tests renewals before cutover, so recurring revenue continues uninterrupted.
A subscription is a billing relationship, not just a record
The reason subscriptions are uniquely hard is where the recurring charge actually originates. In your store, a subscription looks like a record: this customer, this product, this interval. But the charge that renews it is initiated against a payment token stored at your payment gateway, which holds the customer’s payment method and the mandate to bill it. So a subscription is really a billing relationship split between your store and the gateway, and the gateway half is the part that moves money. Migrating only the store-side record, without the gateway relationship, leaves you with a subscription that displays correctly but no longer charges anyone. Understanding this split is the whole key to migrating subscriptions without silently killing renewals.
Keep the same gateway and move tokens with the subscriptions
The safest strategy follows directly from that split: keep the same payment gateway account, and migrate the subscriptions together with their stored tokens and schedules. When the gateway stays the same, the payment tokens and mandates remain valid, so the new platform can be connected to bill against them on the existing schedule, and the recurring relationship survives. This keeps the gateway continuity that subscriptions depend on. Coordinate with the gateway where the platform change requires it, since some gateways have specific processes for associating existing subscriptions with a new integration. The principle is to preserve the billing relationship intact, not to rebuild it from scratch, because rebuilding recurring billing from scratch means re-collecting payment details from every customer, which loses many of them.
Avoid switching gateways in the same move
The single biggest way to make subscriptions harder is to change gateways at the same time as platforms. Moving stored payment tokens between two gateway accounts is a genuinely difficult, sometimes impossible, operation, because the tokens are held securely by the gateway and cannot simply be exported like a spreadsheet; some gateways support a formal, vetted migration of payment methods, and others do not. Bundling that into a platform migration stacks two hard problems together and multiplies the risk to live revenue. So unless you have a deliberate, gateway-supported plan, keep the gateway constant through the platform move and treat any gateway change as its own separate project afterward. One hard change at a time is far safer than two at once, especially when recurring money is involved.
Preserve schedules and prevent double-billing
The failure modes to engineer against are missed renewals and double charges, both of which erode trust and revenue. Preserve each subscription’s next billing date, amount, and interval exactly, and reconcile those between the old and new systems before cutover so the schedule is continuous. Critically, make sure only one system is billing at the moment of switchover, so a customer is never charged twice because both the old and new setups fired, nor missed because neither did. This careful sequencing is why subscriptions cannot be treated like ordinary content in a site move; the timing of the cutover has direct financial consequences. Getting the dates and the single-biller rule right is what keeps the transition invisible to subscribers.
Test renewals before you trust the cutover
Because this is live money, testing is not optional. Before launch, verify in a safe way that the new platform can actually process a renewal against the existing gateway relationship: a test subscription, a controlled real renewal, or the gateway’s testing tools, so you see a charge succeed on the new setup before real customers depend on it. This is the subscription-specific version of the broader rule that you test a migration before going live. Recurring revenue often comes from a loyal minority of customers, echoing the concentration the Ahrefs study finds in traffic, so a billing failure hits your most valuable relationships hardest. Proving renewals work before cutover, rather than discovering a problem when the first renewal date passes silently, is the difference between a smooth move and a revenue incident.
Steps to handle subscriptions in a store migration
- Map the billing relationship: which gateway holds the tokens and schedules.
- Keep the same gateway account through the platform move.
- Migrate subscriptions with their tokens and schedules, coordinating with the gateway.
- Do not switch gateways at the same time unless deliberately planned with support.
- Reconcile billing dates and ensure only one system bills at cutover.
- Test a renewal on the new setup before launch, since it is live money.
Worked example: recurring revenue that never skipped
Consider a membership box business running monthly subscriptions through a single payment gateway. Migrating platforms, the team recognized that the renewals lived at the gateway, so they kept the same gateway account rather than switching, and migrated the subscriptions together with their tokens and next-billing dates. They reconciled the schedules so each subscriber’s next charge date matched, and confirmed only the new platform would bill after cutover. Before launch they ran a controlled renewal and watched the charge succeed on the new setup. When the real renewal dates arrived, subscribers were billed once, on time, at the right amount, and none had to re-enter payment details. The recurring revenue continued without a single skipped or doubled charge.
Limitation: some subscription moves need the gateway’s direct help
It is honest to bound this. Even keeping the same gateway, associating existing subscriptions with a new platform integration sometimes requires the gateway’s direct involvement, and the exact process varies by gateway, so this is one area where you should expect to work with your provider rather than doing it purely yourself. If a gateway change is genuinely unavoidable, treat it as a formal, supported payment-method migration with a real plan, accepting that some tokens may not move and those customers will need to re-authorize. So scope subscriptions as the most complex, most coordinated part of the migration, deserving the most planning and the most testing, precisely because getting it wrong charges, or fails to charge, real customers.
Key points
When you migrate a WooCommerce store, subscriptions are the hardest part, because recurring billing is anchored to payment tokens held by your gateway, not just to a record on your site, so migrating the record alone breaks renewals. Keep the same gateway account and migrate subscriptions together with their tokens and schedules, coordinating with the gateway where needed, and avoid switching gateways in the same move, since moving tokens between gateway accounts is hard or impossible. Preserve each billing date, amount, and interval, ensure only one system bills at cutover to prevent double or missed charges, and test a real renewal on the new setup before launch, because this is live money and often your most loyal customers. Expect to involve your gateway directly, and treat any gateway change as its own planned project. WPBuildAI plans the subscription move around your gateway, preserves billing schedules and amounts, and tests renewals before cutover, so recurring revenue continues uninterrupted. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.