Moving a Paid Community: A Member Export Is Not a Subscription Migration
A cheaper platform can look like an immediate saving until you ask what happens to the members who already paid you. Their email addresses, access rights, and payment arrangements are different records. Moving one does not prove that the others moved with it.
Before choosing a destination, answer a narrower question: How will each existing member keep the access they purchased, and where will their next renewal be collected? That answer determines much of the transition work and its cost.
Separate people, access, payments, and content
Treat these as distinct workstreams:
| What needs to move | Evidence you need | What a successful CSV import alone does not establish |
|---|---|---|
| Member identity | Source and destination identifiers matched to the right person | That the member can sign in or has accepted an invitation |
| Paid access | Purchased entitlement, paid-through date, and destination access rules | That the new account receives the correct spaces or courses |
| Recurring billing | Subscription status, renewal date, amount, currency, and authorized payment route | That the next payment will be collected, or that the old renewal has stopped |
| Community content | The posts, files, course material, and history you intend to preserve | That those objects are included in a member-list export |
Use the export’s actual fields to assess what it covers. A file containing contact details can be useful for invitations while still leaving the payment transition unresolved.
Published migration routes differ
The following entries reproduce the migration portion of the September 1, 2026 documentation research. They preserve the provider’s named operation and its source; they are a dated starting point for checking your proposed move, rather than a current guarantee of eligibility.
| Provider | Recorded operation and limitation | Source |
|---|---|---|
| Skool | The official invite page documents bulk CSV invitations for old customers or members and says they receive access without purchasing; it does not answer whether paid subscriptions can move. | How do I invite members to my community? — checked 2026-09-01; static web retrieval |
| Circle | The paywall migration guide documents moving third-party paid members with trial subscriptions, invitations, and a separate migration-service path for eligible payments. | Migrating member payments to Circle paywalls — checked 2026-09-01; static web retrieval |
| Mighty Networks | The migration guide says paying members cannot be transferred directly or have accounts created for them, and gives a free-trial transition as the recommended path. | How Can I Move Paying Members from Another Platform to Mighty Networks? — checked 2026-09-01; static web retrieval |
| Podia | The migration guide documents product migration and customer import, while explicitly excluding payment plans, subscriptions, and payment details from migration. | Migrating your products to Podia — checked 2026-09-01; static web retrieval |
| Heartbeat | The Circle import guide distinguishes people and content from paid subscriptions and points to a separate subscription import for active subscriptions. | How to import your community from Circle — checked 2026-09-01; static web retrieval |
For example, Mighty Networks’ paying-member migration guide, also retrieved on September 17, 2026, continues to describe member signup and an access trial rather than direct transfer. It recommends grouping members by remaining subscription time and providing an appropriate destination plan. That recommendation does not establish how your old provider will cancel billing or handle unused payments.
Ask the destination provider to confirm the route for the exact source platform, payment processor, plan, and subscription type you use. Obtain the eligibility rules, required member actions, expected schedule, and any service charge before scheduling the move. A service described for one source or payment route should not be assumed to cover another.
The broader documentation evidence guide separates member exports, APIs, invitations, and paid migration. Here, those distinctions become work items in the transition budget.
Start the budget with the overlap period
During a staged move, both platforms may need to remain available. Estimate the actual invoices you will pay through the intended transition, including any old annual commitment that remains payable. Changing platform does not demonstrate that prepaid subscription fees are refundable.
Build a worksheet with these lines:
- Old and destination platform subscriptions during parallel operation.
- Migration-service or connector charges confirmed for your route.
- Content preparation, account matching, access configuration, and reconciliation work.
- Member communication, signup assistance, and billing corrections.
- Ongoing costs that remain after the move, including transaction charges and staff work.
Separate cash outlay from internal staff time. Both matter, but an hour spent by a salaried operator does not automatically create another invoice. Likewise, an old prepaid subscription may create no new cash payment this month while still representing committed spend.
Once the transition is complete, compare the new recurring cost with the old cost on equivalent revenue, transaction, and billing assumptions. The community-platform transaction-fee guide explains why headline subscription prices are insufficient for that comparison.
If the destination produces a positive recurring saving, dividing the estimated transition cost by that saving gives a simple recovery period. Use consistent units and state the assumptions. If the saving is absent or uncertain, do not invent a recovery date; the move needs a separately stated operational reason.
Preserve what members already purchased
Create a transition register from the records you are authorized to use. Include the member identifier, source subscription status, paid-through date, access entitlement, proposed destination route, and confirmed completion state.
Handle groups separately where their obligations differ:
| Member situation | Transition question |
|---|---|
| Monthly recurring membership | Who stops the old renewal, and when can the destination start charging? |
| Annual membership with unused time | How will the remaining purchased access be honored before another paid period begins? |
| Cancelled but still paid through a future date | How will access end without recreating an unwanted renewal? |
| Lifetime access | Which destination entitlement preserves access without requiring a recurring purchase? |
| Failed or disputed payment | Which source records determine access, and who resolves the exception? |
These are planning questions, not promises that every destination supports each outcome.
If you voluntarily extend access beyond what was purchased, model that separately. The extension may defer the next renewal; it is not necessarily a refund, a software charge, or a proven retention benefit. Keep the original paid-through date and the chosen destination renewal date visible so the tradeoff can be assessed.
Verify completion before retiring the old service
Rehearse the approved route with representative cases before moving the full group. Confirm that the intended person can sign in, receives the correct entitlement, and has the expected billing state. Record failures and the manual work needed to resolve them.
During the move, track invitations separately from completed signups, and signups separately from verified access and billing. A count of imported contacts is insufficient to confirm that paid members have transitioned.
Before retiring the old service, reconcile unresolved accounts and check who is responsible for every future renewal. Preserve records needed for outstanding refund and support obligations. Set a completion criterion in advance so the overlap period has an accountable end rather than growing silently.
The decision to change platform should include that workload. A lower ongoing fee can still justify a move, but the saving begins under the conditions you verify after the transition.
Verification scope
The table uses the September 1, 2026 official-source snapshot, retrieved through static web research. Its source dates remain attached to the claims. The September 17 Mighty Networks check supports only the additional description explicitly dated above. Circle’s page did not return readable article text in that later retrieval, and Podia’s page could not be opened, so neither is represented as newly verified.
This article does not measure migration success, support quality, lost revenue, or member retention. The worksheet and completion criteria are editorial recommendations; they are not reports of a performed migration. Source links are ordinary documentation links without referral tracking. Confirm the current terms for your proposed route before committing to a destination.