Switching BJJ Gym Software Without Losing Your Members or Their Belt History

Most academy owners know their software is wrong for them about eighteen months before they do anything about it. The reason for the delay is almost never price. It is fear of the switch: fear that the belt history disappears, that members get charged twice, that the front desk breaks on a Monday night with forty people waiting to check in.

Those fears are reasonable. They are also manageable. Migration goes wrong in a small number of predictable ways, and every one of them can be handled with a plan.

This is the operator's version of that plan, written for Australian academies running direct debit memberships.

First, decide whether you are actually switching

Switching costs you real hours and a small amount of member goodwill. It is worth it when the platform is structurally wrong for you, not when you are annoyed at it.

Structural reasons to move:

• You are paying for a gym platform and using a tenth of it. Pilates studios and 24-hour gyms have different needs to a BJJ academy. If you are paying per-member rates for class packs and PT scheduling you never touch, you are subsidising someone else's use case.
• Belt and attendance data lives outside the system. If your promotion decisions come from a spreadsheet because the software cannot track stripes, mat hours, or time at belt, the software is not doing the one job that is specific to your sport.
• Billing failures are invisible. If you find out about a dishonoured direct debit when the member mentions it at the front desk, you are losing revenue you cannot see.
• Support is offshore and slow. A billing question that takes four days to answer costs you more than the subscription.

Reasons that feel structural but usually are not: a UI you dislike, one missing report, a feature that was promised and delayed. Those are worth a complaint, not a migration.

What actually transfers, and what never does

This is the part most vendors are vague about. Be specific with your current provider and get the answer in writing before you commit to a date.

Transfers cleanly, almost always

Member contact records. Name, email, phone, address, emergency contact, date of birth. This is a flat CSV export and it moves without drama.

Membership plan definitions. Your plan names, prices, and billing intervals. You will usually rebuild these by hand rather than import them, because there are only five or ten of them and manual entry takes twenty minutes.

Attendance history. Usually exportable as a CSV of member, class, and timestamp. Whether the destination can import it is the real question. Ask.

Transfers with effort

Belt and promotion history. Some platforms store this properly, some store it as a free-text note on the member record, and some do not store it at all. If yours is the third kind, your belt history lives in your head and in your instructors' heads. Budget an evening with your senior coaches and a spreadsheet before you migrate, not after.

This is the single most emotionally important data set in a BJJ academy. A member who has been at blue belt for three years and finds their promotion date wiped will take it personally, and they will be right to.

Kids grading records. Stripes, grey and yellow belt progressions, and age-group transitions. Same problem as adult belts, usually worse, because kids programs generate more grading events.

Rarely transfers, plan to lose or rebuild

Historical invoices and payment receipts. You can almost always export a CSV of transactions, but they will not become clickable invoice records in the new system. Export the full transaction history to CSV and keep it. Your accountant will want it and the ATO expects you to retain records for five years regardless of what software you are running.

Signed waivers. Most platforms store the waiver as a rendered document or a timestamped acceptance flag tied to their own terms text. That acceptance does not transfer meaningfully, because the document it refers to lives on their servers. Assume you are re-papering waivers on the new system.

Automated message history. The record of what emails and SMS went to which member. Rarely exportable, rarely missed.

Direct debit authority. The big one. See below.

The billing changeover is the whole game

Everything else is data entry. Billing is where migrations actually fail, and it fails in one of two directions.

Gap: you switch off the old debits before the new ones are authorised, and a fortnight of revenue silently does not arrive. For a 120-member academy at $180 a month, a missed fortnight is roughly $10,000.

Overlap: both systems run a debit in the same cycle and a large slice of your membership gets charged twice. This is worse than the gap. Refunds take days to land, members post about it, and the ones on tight budgets have a dishonoured rent payment because of you.

Direct debit authority does not simply move

In Australia, a direct debit arrangement is a legal authority from the member to a specific biller, under a Direct Debit Request and its service agreement. That authority is generally tied to the provider that holds it, not to you.

Some processors will cooperate on a bulk mandate migration, where the existing authorities are transferred with both parties' agreement and members are notified. Stripe, for instance, runs a data migration process for exactly this. It requires the losing provider to cooperate, and that cooperation is not guaranteed when they are losing your business.

Plan on the assumption that you will need fresh authority from every member, and treat a successful mandate transfer as a bonus. Start that conversation with both providers in week one, not week three.

Re-authorisation is a retention event, so treat it like one

Asking 120 members to re-enter their bank details is the riskiest moment in the whole process. Every person who does not complete the form is a member you have effectively cancelled.

What works:

• Tell them why, once, plainly. "We are moving to a system built for jiu-jitsu so we can track your grading properly and stop billing errors. It takes two minutes and you only do it once."
• Send a direct link, not instructions. Every extra step loses people.
• Do it in person at the front desk for the first week. A tablet at reception converts far better than an email. Catch people as they check in.
• Chase by phone, not email, after day five. The stragglers are not ignoring you, they are busy. A thirty second call fixes it.
• Give a hard cutover date and hold it. Open-ended migrations never finish.

Expect roughly 70 to 80 percent to complete in the first week if you push at the desk, and to spend the following fortnight chasing the rest. Budget for two or three genuine losses. Members who were already drifting will use the friction as their exit.

Time the switch to your billing cycle, not your calendar

Do not cut over mid-cycle. Pick the boundary.

If you bill on the 1st, run the old system's debit on 1 August, cut over during the first week, and have the new system take its first debit on 1 September. That gives you a clean month with exactly one billing system live at a time, and it makes reconciliation trivial: one month, one provider, one set of numbers.

If you bill fortnightly or on member anniversary dates, this is harder. The usual answer is to move everyone onto a common billing date as part of the migration, pro-rating the difference. Members barely notice a one-off pro-rata adjustment if you explain it, and you get a far simpler operation forever after.

A three-week switch timeline

Week one: extract and verify.

Request the full export from your current provider in writing. Get member records, attendance, transactions, and whatever grading data exists. Open both providers' conversations about mandate transfer. Rebuild your membership plans in the new system by hand. Do not import anything yet.

Separately, sit down with your senior coaches and reconstruct belt and stripe history for every active member. This is the task everyone underestimates. For 120 members expect two to three hours.

Week two: load and reconcile.

Import members and attendance. Then reconcile properly: active member count, total monthly recurring revenue, and count of members per plan. All three must match the old system before you go further. If your MRR is out by $400, find the reason. It is usually a handful of members on legacy pricing that did not map to a current plan.

Run both systems in parallel, with the new one read-only. Nobody is billed from it yet.

Week three: authorise and cut over.

Announce the change, open re-authorisation, and put a tablet at the front desk. Chase daily. On the cycle boundary, disable billing in the old system before enabling it in the new one, and confirm the old one is off by checking it yourself rather than trusting a support email.

Take the first debit run. Watch it land. Keep the old system's account open in read-only mode for at least three months, because you will need to look something up.

Contract traps to check before you sign anything

Read your current agreement before you announce anything internally.

• Notice period. Thirty days is common, ninety is not unheard of. It runs from written notice, not from when you stopped using the product.
• Minimum term and early exit fees. Some contracts auto-renew annually unless you cancel inside a window.
• Data export terms. Check whether export is included or a paid service, and whether there is a time limit on requesting it after cancellation. Some providers cut access on the termination date.
• Per-member pricing on the way out. If you are billed per active member, deactivating members before the final invoice can save real money. Do it after you have exported, not before.

On the incoming side, the questions worth asking are: what does it cost when I grow to double this size, who owns the data, can I export it myself at any time without asking, and what happens to my members' billing if I leave.

Any vendor that hesitates on the last two has told you something important.

Frequently Asked Questions

How long does switching gym software actually take?

Three weeks of calendar time for a single-location academy of 50 to 200 members, of which maybe eight to twelve hours is your actual work. The long pole is member re-authorisation for direct debit, not data import.

Will I lose my members' belt history?

Only if you do not extract it first. Some platforms store grading properly and export it, others keep it as an unstructured note, and a few do not track it at all. Check which kind yours is in week one, and reconstruct it with your coaches before you migrate rather than after.

Can my members' direct debits transfer automatically?

Sometimes, with the cooperation of both providers, through a formal mandate migration. It is not guaranteed and it depends on the provider you are leaving agreeing to help. Plan for fresh authorisation from every member and treat a transfer as a bonus.

When during the month should I cut over?

On your billing cycle boundary. Run the final debit on the old system, cut over in the following days, and take the first debit on the new system exactly one cycle later. Never run two billing systems into the same cycle.

How many members will I lose in a migration?

If you handle re-authorisation at the front desk and chase by phone, two or three out of a hundred, and they are almost always members who were already close to leaving. If you send one email and hope, it can be ten times that.

Should I keep paying for the old system after switching?

Keep read-only access for about three months if the contract allows it. You will want to check a historical payment or an old member record at least once. Do not keep billing enabled on it under any circumstances.