Switching membership software: what to export and check before you move
A practical checklist for moving members, billing dates, balances, and family records from one membership system to another, including the parts that usually cannot be moved.
Switching · 5 min read
By Rovari · Updated
To change membership software you need an accurate list of your members, what each is paying for, and when each last paid. You also need to make sure nobody is charged twice, or missed, while the old and new systems overlap.
Export everything first, then decide what to move
Before choosing a date to switch, ask your current provider what you can export and in what format. Request a full export early, even if you are not ready to move, and compare it with what the old system shows on screen. Resolve any differences before moving.
A useful export usually includes:
- People: names, contact details, dates of birth for children, and the ID the old system uses for each person.
- Family links: which adults are responsible for which children, and who pays.
- Memberships: each member's plan, start date, and the date they are paid through.
- Balances: any amount a member owes or is owed.
- Signed waivers and agreements, as documents you keep even if they are not imported.
- Class schedules, prices, and plan descriptions, so you can rebuild your setup.
Plan for payment details
Saved cards and bank details need their own migration plan. Some processors support a secure transfer of stored payment data; Stripe documents a process coordinated with the previous processor. This is separate from a member CSV import. In other switches, members enter a payment method again. Do not put raw card numbers into your member spreadsheet.
Sources:[1]
Ask your current provider and your new processor what is possible before you set a timeline. If members must re-enter their cards, give them time to do it before their next payment is due, and keep a list of who has not.
Use paid-through dates to avoid double charges
A member who already paid for the current month should not be charged again for the same coverage. Confirm what each system means by a paid-through date, including whether that day is covered. Import the supported value, preserve the agreed billing schedule, and verify the next charge instead of assuming the date alone prevents a duplicate debit.
Check a sample by hand. Pick members on different plans and billing days, and confirm that the new system's next charge date matches what each of them expects.
Clean the data before importing
- Merge duplicate people before exporting, or know how the import will flag them.
- Check that every child is linked to at least one responsible adult. The family roles guide explains which links to record.
- Look for adults who share one email address. Ask how the new system identifies each login and resolves shared addresses.
- Remove or mark former members so they are not invited.
Prefer an import that previews the result, with counts and a list of rows it could not accept, before it writes anything. Fix problems in the source file and preview again, rather than correcting records one at a time afterwards.
Limit access to exports containing personal information. Keep a secure backup for the agreed transition period and decide when temporary copies will be removed under your retention requirements.
Sources:[2]
Plan the overlap
Choose a switch date and decide which system handles signups and each billing period. Validate the new setup before stopping old collection. At the agreed handover, confirm that the old system cannot charge a period the new one will collect. Keep read access to past payments or agree how to archive them. Decide how to delay the move if the final checks fail.
- Import a test copy of your data.
- Check a sample of members, families, and balances by hand.
- Ask a few staff members and members to confirm they can sign in.
- Confirm the new payment setup and rehearse the first billing period before authorizing the handover.
- Stop old collection at the agreed boundary, import the final changes, and reconcile them before starting new collection.
- Invite members to add payment details if the switch requires it.
- Follow up with anyone who has not added a payment method before their paid-through date.
- Compare the first new invoices and payment results with the agreed schedule; resolve missing or duplicate charges.
Example migration reconciliation checklist
Record the old-system total, the import preview, and the accepted result side by side. Compare both totals and individual records; matching counts alone do not prove that the right people or amounts moved.
| Check | Evidence to keep | If it does not match |
|---|---|---|
| People and family links | Source IDs, accepted rows, duplicates, and each child’s responsible adults. | Resolve missing or ambiguous links before inviting anyone. |
| Membership coverage | Plan, payer, covered people, and the agreed paid-through dates. | Correct mappings and check a sample across plans and billing days. |
| Money | Opening debit and credit totals, with individual balances and next invoice dates. | Reconcile each difference and confirm which system will collect it. |
| Bookings and other records | Class packs, bookings, waivers, and history that must be imported or retained separately. | Agree what will be rebuilt or archived before the old access ends. |
| Payment readiness | Processor confirmation or the list of payers who must add a method. | Delay collection for unready accounts and follow up before coverage ends. |
| Collection ownership | Confirmed old-system stop and new-system start for each billing period. | Delay the handover; do not restart both systems for the same period. |
For example, a studio moves on June 20 while a member is paid through June 30 inclusive. Confirm that the imported coverage includes June 30, review the July 1 invoice, and verify that only the new system can collect that next period. If account setup or reconciliation is incomplete, follow the agreed delay plan instead of enabling duplicate collection.
Questions to ask a new provider
- Which file format does the import accept, and can you see the template before committing?
- Which fields are imported, and which are left behind?
- Can the import carry paid-through dates and opening balances?
- What happens to saved payment methods?
- How are members invited, and what do they see first?
- Can you export your data again if you leave?
Sources
Sources checked October 13, 2026. Sample policies and settings are illustrative.
- Stripe: Customer and Payment Data Migrations
Processor-managed payment-data migration, separate from importing member records.
- FTC: Protecting Personal Information, a Guide for Business
Collecting only necessary personal information, limiting access, and planning retention.