You do not move your data. You move a list: names, contact details, the plans people are on with their dates and remaining sessions, and a few profile fields such as notes and join dates. Attendance history, past payments and signed waivers stay behind. Nobody automates this, MoveMembers included: you export a file from the old tool, check how its columns are matched on the import screen, import up to 5,000 rows a file, and rebuild the rest by hand.
That is a worse promise than the one you were probably given elsewhere, and it is the true one. The useful question is not whether you lose history. You will. It is whether you ever open that history again, and for most gyms the honest answer is no.
What actually crosses over
The import screen reads your column headings and matches the ones it recognises: name (or first and last name), email, phone, plan, start and renewal dates, credits left, status, join date, birthdate, notes and tags. You see every match before anything is written. Name is the only column that is required, and a column the importer cannot place is left out, however carefully the old system filled it in. Each row becomes a member profile that you finish filling in over the following weeks.
| What you have today | What happens to it |
|---|---|
| Names | Carried. The only required column. |
| Email and phone | Carried, if those columns exist in your file. |
| Current membership | Carried when the plan cell holds the name of one of your products, as you read it on screen. A plan name that matches nothing still creates the member, without a membership. |
| Join date | Carried, if your file has a join date column. Without one, everyone gets the date you ran the import. |
| Attendance history | Lost. It stays in your export file and nowhere else. |
| Payment history | Lost. Revenue reporting starts from your first day. |
| Member notes | Carried, if your file has a notes column. Notes kept anywhere else in the old tool are lost: retype the ones that matter. |
| Belts, grades, levels | Not read by the CSV import. Set them on the profile afterwards. |
| Signed waivers | Lost as records. Members re-sign, or you keep the old PDFs in a folder. |
| Cards on file for auto-pay | Never transfers between any two systems. See below. |
The three losses that actually sting
- Year on year revenue. For twelve months you cannot compare this March to last March inside the software. Fix it in five minutes before you leave: write last year's twelve monthly totals into one spreadsheet row. That is the only piece of the payment history you will genuinely miss.
- Who is slipping away. At-risk and inactive lists are built from check-ins, so they mean nothing until you have about four weeks of your own attendance data. Plan on running the first month blind on retention, and keep whatever manual habit you use today until then.
- Member since, when your export has no join date. Everyone then shows as joined on import day, so your new-members-this-month number will be nonsense for the first month. If the old tool exports a join date, keep that column in the file; if it does not, ignore the number rather than trying to repair it. Nobody has ever been helped by an accurate join date on a member who has been coming for six years and knows it.
The order of operations
- Export everything from the old tool first, while you are still a paying customer. Members, attendance, payments, waivers, the class schedule. Do this before you sign up anywhere and before you cancel anything.
- Build the empty shell. Memberships and prices first, then classes and the weekly schedule. The plan column is matched on the product name, so give your products the names the old tool uses, or rename the plans in the file. A member whose plan matches nothing lands without a membership, and you attach it from the profile.
- Read the column matches on the import screen, and leave out any column you do not want carried. Delete the rows for people who left two years ago while you are in the file.
- Import, up to 5,000 rows per file. A bigger file is refused with its row count rather than cut short, so split it and import the parts one after the other.
- If an import goes wrong, undo it. For 24 hours, Undo this import removes the profiles and memberships that import created. Running a corrected file again updates the members it finds by email or phone instead of creating them twice.
- Correct the statuses. Without a member status column, everyone lands as active. Freeze or archive the people who are not.
- Re-collect recurring payment authorizations. This is the real work. See the next section.
- Run one week in parallel on check-in only, then stop. Two systems taking bookings is how you sell the same twelve spots twice.
- Cancel the old subscription last, and only after you have opened your export files and confirmed they are not empty or scrambled.
The payments part is harder than the data part
Stored card details do not move between systems. That is a card network and processor rule, not a software limitation, and any vendor who tells you otherwise is describing something else. If your current tool bills through its own merchant account, those payment mandates die with that account, and every member on auto-pay has to enter their card again.
MoveMembers takes card payments through Stripe on your own Stripe account. We never hold the money and take no commission on what you collect. Be clear on what it does not do today: there is no open-ended autopay that renews until someone cancels. What exists is a fixed run of monthly instalments the member picks when buying a product, and MoveMembers creates its own Stripe customer and subscription for it, so it never picks up a subscription the old tool created, even inside the same Stripe account. Cancel the old subscriptions in your Stripe dashboard as each member moves over, or they keep charging next to the new ones.
What that looks like in practice: send everyone who was on auto-pay their member portal link, and tell them to buy their next membership there, in one payment or in monthly instalments if you set the product up that way. There is no button on your side that charges them, and you cannot enter a card for them. Then keep a list of who has not done it and chase it at the front desk over the next two or three weeks. Assume the last handful get sorted in person. Also worth saying plainly: there is no SEPA direct debit and no bank mandate here. If your billing currently runs on direct debit, that arrangement does not carry over and there is no equivalent to switch it to.
Pick the month, not just the day
Switch in the first days of the month, right after your billing run has gone through. Everyone on a monthly plan has just paid, which buys you a full cycle to finish re-authorizations before anyone is due again. Switching three days before billing means chasing cards and running a billing cycle at the same time.
Two months to avoid: your biggest intake month, and any month with a promotion running. Do the import itself on a quiet weekday morning, never before a Saturday.
Size the plan before you import, not after
Price is driven by active members, not by how many rows are in your file. Free covers 20 active members, Pro 200, Max unlimited, at 0, 99 and 199 USD a month, or 2490 and 4990 THB. Without a member status column everyone lands as active on import, so count in the spreadsheet before you upload: if your file has 180 names but 90 people actually train, delete or park the dormant rows and size the plan on the 90. If you import them anyway, archive them afterwards, because archived and frozen members both stop counting. Automations sit at the Pro tier, which matters if you were relying on custom renewal messages in the old tool; the built-in reminder a week before a membership ends is free on every plan. Full breakdown on the pricing page.
Keep the old export as your archive
This is the part that makes the whole thing survivable. Put every export file in one folder, name it something like old-software-export-2026-08, and keep it in two places: one cloud drive, one local. That folder is the answer to "what did we bill her last year" and "when did he actually start". You will open it three times in the first two months and then never again, which is exactly the right outcome.
The same works in reverse, which is the only reason you should believe any of this. MoveMembers exports members to CSV, attendance to CSV, and the whole account as a backup file. If you leave in two years, you leave the same way you arrived, and you will lose the same history on the way out.
What we do not do
- No automated migration. There is no API pull from Mindbody, Glofox, PushPress or anyone else, and no service where we handle it for you. File import only.
- No history import in any format. Attendance and past payments cannot be loaded, even if you clean them perfectly.
- No accounting sync. You export CSV and hand it to your bookkeeper.
- No direct debit or bank mandates. Stripe cards, cash and the local methods you already take.
The gyms that regret switching are the ones who expected the software to carry their past across for them. The ones who do not regret it decided in advance which twenty members' notes were worth retyping, saved the export, and let the rest go.