Moving paid members without duplicate charges or lost access
By Simon
A paid-member migration runbook that separates identity, billing and access, then tests exceptions before any live cutover.

AI-generated conceptual illustration: reconcile parallel records and approve a controlled handover; shared payment infrastructure does not make migration automatic.
Consider a member who has turned off renewal but still has paid access. Import them as inactive and you could take away something they've already bought. Import them as a new subscriber and you could restart a payment they deliberately stopped.
Your migration needs to preserve both their remaining access and their cancellation. Getting the account into the new system doesn't settle either question.
Use this runbook for planning, not as instructions to change live billing. The source platform, destination and payment provider need to agree on the execution sequence for your account arrangement. Don't cancel subscriptions or disconnect an application on the strength of a general article, including this one.
Find out what can move
"Both platforms use Stripe" isn't enough to approve a migration. Ask whether the source uses Stripe Subscriptions, which account holds the customer and payment records, what the destination can import and who will collect future payments.
Memberful's process for importing existing Stripe Subscriptions includes recreating plans and coupons, mapping products and prices, and having its team review the mapping. It also says deauthorizing the old app differs by platform and should be discussed with support. Assign that work before anyone disconnects the application.
Stripe's Billing migration toolkit requires a Billing integration and a default payment source for customers who will be charged automatically. A move from another processor also requires a payment-data import first. Confirm that this route fits your accounts and destination before using its instructions.
Get a written feasibility answer before announcing the move, whether you're considering Stackmodo or another service. Cover payment methods, currencies, discounts, trials, tax configuration and any action customers must take. If some members need to authorize payment again, put that in the plan and the customer notice.
Reconcile identity, billing and access separately
Keep three inventories connected by an internal migration reference. Store them somewhere restricted to the people doing the move. Include provider record IDs where they're needed, but never API keys or payment credentials.
Inventory: Identity
Minimum questions it must answer: Which source member maps to which destination account? How will they sign in? Are there duplicates or changed email addresses?
Inventory: Billing
Minimum questions it must answer: Which subscription and customer records apply? Who collects next, for what amount and currency, and on what date? What discounts or pending changes apply?
Inventory: Access
Minimum questions it must answer: What can the member use now? When does that right end? Is the right prepaid, trial, complimentary or permanently purchased?
Record source values, proposed destination values and the values that actually arrive. Give discrepancies a column and an owner. A matching member count won't catch a changed price or an access end date that's wrong.
View full-size imageUse one migration reference to reconcile separate identity, billing and access records. This is a planning model, not a platform data schema.
Put a snapshot time on every export. Someone may cancel, update a card or pay an overdue invoice after you take it. Your cutover plan needs a way to capture those final changes or a controlled pause supported by the providers.
Test the awkward cases before setting a date
An import of active monthly members won't tell you much about annual access or canceled renewals. Build a test cohort with varied billing and access states, using sandbox or test environments where available. Don't create live charges just to prove the importer works.
Member state: Active monthly
Acceptance test: Next charge has the intended amount and date; only the designated system can collect it
Member state: Annual prepaid
Acceptance test: Remaining access survives without an immediate replacement charge
Member state: Trialing
Acceptance test: Trial end and first collection rules match the agreed offer
Member state: Past due
Acceptance test: Existing debt and recovery state have an explicit treatment
Member state: Renewal canceled, access remaining
Acceptance test: Access continues to the agreed end without restarting renewal
Member state: Complimentary
Acceptance test: Access remains free and has the intended expiry, if any
Member state: Discounted or legacy plan
Acceptance test: Price and discount duration survive, or the change is explicitly agreed
Memberful's import guidance specifically asks how canceled subscriptions should be handled: some systems cancel the Stripe subscription immediately but leave access running through the billing period. You need the access inventory to catch that distinction; the subscription's status label won't do it for you.
Stripe provides a sandbox route for testing its toolkit. After a successful test import, check the application too. Sign in as a test member, open paid content, visit the account page and confirm the renewal information it displays. The records and the member's experience both need to be right.
Name the person who can stop the cutover
One migration owner should hold the short, explicit sequence approved by all involved providers. It needs to say when old signups stop, when the final changes are captured, when imports run and when the new application takes over access and billing actions.
Check automated messages before importing. Memberful warns that subscription moves can trigger unintended welcome emails or churn notifications in connected apps; its checklist includes disabling specified emails and automations. Follow your provider's instructions selectively. Turning off every operational notification could leave nobody watching payment failures.
Write down the billing schedule that prevents duplicate charges. For moves from a third-party or home-grown system, Stripe's toolkit guidance says to create new subscriptions first and cancel old ones before they charge again. When a billing date is close to migration, it describes scheduling the new subscription after the old subscription's last charge. That sequence belongs to that route. Don't copy it into a different migration without approval.
View full-size imageEach gate needs evidence and an owner. Stopping before live billing changes is different from trying to reverse them afterward.
Immediately before live work, use a go/no-go checklist:
Every plan and exception has an approved mapping.
The next collection owner and date are known for each migrated subscription.
Prepaid and canceled-but-entitled access passed the rehearsal.
Staff know which messages are paused and who will restore them.
Support has the member notice, sign-in instructions and escalation contact.
The team has a documented stop point and a recovery procedure for partial completion.
Hold back any group with an unresolved identity, money or paid-access mismatch. If the rest can move independently, document the split and which system will serve the delayed members. If they can't, stop the cutover.
Check the result before closing the old system
Compare the imported records with your inventories and check the next billing schedule. Look for missing members, duplicate billable subscriptions, changed dates and access that ends too soon. Keep discrepancies on the list until someone resolves them.
Tell customers what changes, what stays the same, whether they need to act, where to sign in and how to get help. Don't promise that passwords, mandates or payment methods will transfer until the providers confirm how.
Be precise about recovery. Restoring a website won't undo a charge or bring back a canceled subscription. If collection has already happened, the recovery owner needs provider-approved remediation and customer communication. Rerunning the import without checking could make things worse.
Keep the old system available for the agreed reconciliation period, with collection and automations controlled by the cutover plan. Before closing it, the migration owner should account for every unresolved exception and verify the intended next charge and paid-through date in the destination. Include the member who canceled renewal in that check: they should be able to use the access they paid for, with no new renewal scheduled.