How to Migrate Your Subscription Business to New Software Without Double Billing

Last updated: November 2026

Most rental and subscription businesses don't start on the software they end up on. They start with a shop plugin, a spreadsheet and a payment provider, and it works until it doesn't. Then comes the question that keeps founders on their old setup far longer than they should be: how do we move hundreds or thousands of running subscriptions without breaking anything?

This guide walks through what a subscription migration actually involves, where it goes wrong, and how to plan a cutover that your customers barely notice.

The short answer: A subscription migration moves three things: customers, payment details and contracts. Payment details are the hardest part and depend on your payment provider, so plan that first. Then import contracts with their real start dates and billing dates, run old and new systems side by side for one billing cycle, and switch off billing in the old system the moment it starts in the new one. Charging a customer twice is the one mistake you can't take back.

Signs it's time to migrate

You don't need new software because you're growing. You need it when the old setup starts costing more than the move would. Typical signs:

• Returns, swaps and buyouts are tracked in spreadsheets next to your shop system.
• Nobody can say quickly which serial number is with which customer.
• Failed payments are chased by hand.
• Your shop plugin treats a rental like a digital subscription, with no idea that a product needs to come back.
• Adding a new sales channel, market or payment method means a development project.

If several of these sound familiar, our guide to challenges that stop subscription businesses from scaling goes deeper, and our comparison of subscription management software for physical products covers what to look for in a replacement.

The three things you're actually moving

For physical product subscriptions, contracts carry more than they do for digital ones. Each contract is tied to a specific unit with a serial number, a minimum term, return obligations and sometimes a buyout price. All of that has to arrive intact.

Payment details: the part to plan first

Card numbers and bank mandates are stored by your payment provider, not by your shop or billing tool. That has one big consequence: if you keep the same payment provider, your saved payment details usually stay where they are, and the new platform connects to them. The migration gets much simpler.

If you're also changing payment provider, the details have to move between providers, and that's a formal process:

• It runs between the providers, not through you. Card data is moved securely from one PCI-compliant provider to the other. Stripe's migration guide describes the old provider encrypting the data and uploading it to a dedicated server.
• The old provider's export sets the timeline. Stripe notes that providers can take anywhere from a few days to several months to produce the export, with Stripe's own import typically completing within 10 working days after it receives valid data.
• Run both providers during the switch. Adyen recommends sending new sign-ups to the new provider while existing customers keep being charged by the old one until their details are imported. Adyen also says the process usually takes 10 days or more.
• Expect a temporary dip in approvals. A new merchant account may not be recognised by card issuers at first. Stripe recommends ramping up volume gradually rather than switching everything at once.

Whatever the route, ask your current provider early what they can export and in which format. It's the step most likely to delay everything else. If you're also reviewing your payment setup, our article on subscription management software vs payment gateways explains who does what.

Contracts: keep the real dates

The most common contract mistake is importing every subscription as if it started on migration day. That resets minimum terms, moves end dates and shifts billing dates, and customers notice all three.

For each contract, carry over at least:

• the original start date, so minimum terms and end dates stay correct,
• the next billing date and billing frequency,
• the current price, including any discounts or vouchers,
• the product and the serial number of the unit the customer has,
• renewal settings and any agreed buyout terms.

This means your new system has to accept start dates in the past. Check that before you choose it.

Clean your data before you import it

A migration is the cheapest moment you'll ever have to fix your data. Before exporting:

• Merge duplicate customers. The same person with two email addresses becomes two customers with split histories.
• Reconcile your assets. Match every active contract to a real serial number. Products that can't be matched need a physical check. Our guide to asset tracking for physical products explains why this matters long after migration day.
• Close dead contracts. Ended subscriptions with no product outstanding don't need to come across as active.
• List open payments. Decide whether outstanding invoices are collected in the old system or moved to the new one, and don't do both.

A cutover plan that avoids double billing

1. Set up and test the new platform with a handful of test subscriptions: checkout, billing, invoices, emails, returns.
2. Send new customers to the new platform first. From a set date, every new order is created there. Existing customers stay on the old system for now.
3. Import existing contracts with their real dates, after a final data clean.
4. Pick a cutover point per billing cycle. For each customer, the last charge happens in the old system and the next one in the new system. Never both.
5. Switch off billing in the old system as soon as each contract is live in the new one. Stripe's guide gives the same warning: cancel the old subscriptions as soon as the new ones are active, or customers get billed twice.
6. Watch the first full billing cycle closely. Compare expected and actual charges, and look for unusual decline rates.

Tell customers only what they need to know

Many customers don't need to hear about a migration at all if their payment details move with them. Two things are worth checking:

• Automated emails. Importing a contract can trigger a "welcome" or "subscription started" email in some systems. Decide whether you want that before you import thousands of contracts.
• New customer portal. If customers will manage their subscription in a new self-service portal, send one clear email explaining what changed and how to log in.

If customers do need to re-enter payment details, give them a simple link, a reason and a deadline, and plan for some of them to miss it. Our guide to failed payment recovery covers what to do next.

How circuly supports a migration

circuly is subscription management built for physical products. It connects to your existing shop system and your payment service provider rather than replacing them, which keeps migrations smaller:

• Your payment provider stays connected. circuly is not a payment provider itself. It works with your existing one, such as Stripe or Adyen, through its payment service provider connection.
• Your shop system stays too. circuly integrates with shop systems including Shopify, WooCommerce, Magento, Saleor and WordPress, as well as headless setups. If you're moving to Shopify at the same time, read the 7 things to audit first.
• Bulk import with real dates. You can upload subscriptions in bulk from a CSV file, with an error report for any rows that need fixing. A setting allows start dates in the past, so original terms and end dates stay correct.
• Bulk processing of existing orders. Orders already in circuly can be turned into subscriptions in bulk, with serial numbers assigned in the same step.
• Duplicate clean-up. Duplicate customer profiles can be merged, moving subscriptions, orders, transactions and payment methods into one profile.
• Every unit tracked from day one. Imported contracts are tied to serial numbers in circuly's asset tracking, so returns, swaps and buyouts work from the first day.

Thinking about a move? Book a demo and bring a sample of your current data.

FAQs about migrating subscriptions

How long does a subscription migration take?

If you keep your payment provider, the work is mostly data preparation and testing, and can take a few weeks. If you change payment provider, the provider-to-provider data transfer usually sets the timeline, and the old provider's export can take from days to months.

Will customers have to enter their payment details again?

Not if you keep your payment provider, or if your old and new providers can transfer stored details between them. Customers only need to re-enter details when neither is possible.

Can I migrate in stages?

Yes, and it's usually safer. Send new customers to the new system first, then move existing customers in batches, for example by billing date or by market.

What's the biggest risk in a subscription migration?

Double billing: a customer charged by both the old and the new system in the same cycle. Prevent it by switching off billing in the old system for each contract as soon as it's live in the new one.

Should I migrate ended subscriptions too?

Only if a product is still outstanding or you need the history for reporting or accounting. Otherwise, archive them in an export and keep the new system clean.

Related reading:

• ERP for Subscription Businesses: What It Can and Can't Do
• How circuly Connects to Your Existing Tech and Tools
• The Tech Stack You Need to Run a Subscription Business Online
• What is Rental Management Software?