Most studio migrations don't go badly because the software is bad. They go badly because the owner assumed everything would come across, told members nothing, and then spent a week at the front desk apologising for a card decline nobody warned anyone about.
So here is the honest inventory. We built a studio importer that takes Mindbody and MindBody-shaped exports — clients, outstanding balances, the schedule — and everything below is written from what that data actually contains, not from what a sales page would like you to believe.
What moves cleanly
Clients. Names, phone numbers, emails, addresses, dates of birth, emergency contacts, notes. The phone number is the identity key that matters — it's how a member will look themselves up at the front desk and how they'll log into a member portal. Clean the duplicates before you export, not after; two records for the same person with one pack each is the single most common mess.
Outstanding credit and pack balances. If someone bought a 10-class pack and used four, the remaining six are a real obligation and they import as a real number. This is the part owners are most nervous about and it's actually the most mechanical: remaining credits, expiry date, and what class types the pack is valid for.
The class schedule. Class types, the recurring weekly grid, instructors, room capacity. You will rebuild a few oddities by hand — the Saturday workshop that only runs in summer, the one class with two instructors — but the 90% that is "Vinyasa, Tue 6pm, Studio A, 22 mats" moves as a template that regenerates future sessions.
Memberships in the abstract. The plan definitions — name, price, billing interval, what it entitles — recreate easily. The billing attached to them does not. See below.
What doesn't move cleanly
Historical attendance detail. You can usually get counts and last-visit dates. You generally cannot get a faithful row-per-booking history going back four years with the instructor, the room, the cancellation reason and whether it was a late cancel. Some of it isn't in the export; some of it is in a shape that only means something inside the old system. Decide what you actually need: "how many classes has this member ever taken" and "when did they last come in" are worth importing as summary fields. A forensic booking log usually isn't, and you can keep read-only access to the old account for a few months if you're worried.
Signed waivers. The text of your waiver moves. The signatures don't, or at least you shouldn't want them to — a signature is a record of a person agreeing to a specific document at a specific time, and a row copied between databases is not that. Plan to re-collect signatures at first check-in. It takes ten seconds on a tablet and it leaves you with a cleaner legal position than you had before.
Automations and templates. Nobody's automations migrate. Treat this as a feature: most studios are carrying six automations they set up in 2022 and no longer understand. Rebuild the three that matter.
The card problem, in detail
This is the single most underestimated part of any studio migration, so read this part twice.
When a member saves a card, you don't store the card — your payment processor does. What your studio software holds is a token: a meaningless-looking reference that says "charge the card the processor has on file under this id." That token is only valid for the processor account that issued it. It is not a card number, and it is not yours to move.
Which means there are exactly two outcomes:
- Your processor can transfer the tokens. If you're staying on the same processor and that processor supports a vault migration to a new platform, the saved cards can follow. This is a request you make to the processor, it takes time, and it usually involves a form and a compliance review. Start it the week you decide to switch — not the week before cutover.
- It can't, or you're changing processors. Then every member with a recurring membership has to re-enter their card. There is no clever workaround. Anyone who tells you otherwise is describing a card-number export, which is exactly the thing PCI rules exist to prevent.
The failure mode isn't the re-entry. It's the surprise. A member whose 6am auto-draft fails silently, gets a dunning email from a brand they've never heard of, and shows up to a locked door has had a genuinely bad experience — and they'll blame you, correctly, for not telling them.
So tell them. Two weeks out, one week out, and the day of: a short message that says the studio is moving to a new system, their pack balance and membership are coming with them, and they'll need to add their card once at the front desk or in the portal. Frame it as a thirty-second task, because it is. In our experience the studios that send this message answer almost no questions at the desk; the ones that don't spend a week answering the same question forty times.
Why imported SMS consent should land as pending
Your export will very likely include a column that looks like marketing consent. Do not trust it into an opted-in state, and don't let a vendor flip it on for you.
Two reasons, one legal and one operational.
Legal: consent is consent to be texted by you, evidenced by a specific action at a specific time. A boolean in a CSV with no source and no timestamp is not evidence. If a member complains, "it was true in the old database" is not a defence you want to be making.
Operational: carrier A2P registration — the process that gets your studio's texting approved on US carrier networks — asks how you collect opt-in and expects the flow to be real and provable. A freshly imported list marked wholesale as opted-in, followed by a blast, is how a brand-new number gets filtered or a campaign gets rejected. We wrote about that failure mode in detail in the A2P registration guide.
Our importer lands consent as pending for exactly this reason: imported members exist, can be booked, can spend their credits, and simply aren't in the marketing audience until they opt in with a recorded checkbox — at the front desk, in the portal, or on a check-in screen. You rebuild a smaller, provably consented list over a few weeks. That list performs better anyway, because everyone on it chose to be there.
If you want to see what a dry-run import of your own export actually produces — including how many clients, how much outstanding pack liability and how many consent records you'd start with — book a demo and bring the file.
A migration sequence that works
- Dry-run the import first. A real importer should let you run the whole thing and write nothing — you get a report of how many clients it found, how many it would skip, which rows are malformed, and what the balances total. Run it, read it, fix the export, run it again. Ours takes a
dryRunflag for precisely this. Do this three times if you need to; it costs nothing. - Reconcile balances before you go live. Pull an outstanding-liability report from the old system on the same day you export. Remaining credits × unit price, plus gift balances. Then pull the same number out of the new system after import. They should match to the dollar. If they don't, find out why now, while the old system is still authoritative — not in month two when a member insists she had four classes left.
- Communicate the card re-entry before it surprises anyone. Covered above. This is the cheapest insurance in the whole project.
- Run one week in parallel. Bookings still go through the old system; staff also check people in on the new one. You are not testing the software here — you are testing your front desk, your instructors and your own muscle memory. Everything you discover in this week is something you would otherwise have discovered in front of a customer.
- Cut over on a quiet day. Monday morning, not Saturday before the 9am that fills up. Keep the old account readable for at least 90 days.
When you should just stay
Honest answer: if your current system works, your staff know it, and your complaint is that it costs more than you'd like, a migration is a bad trade. Switching platforms costs you a week of attention and a small amount of member goodwill. That's worth paying when the old system is actively blocking something — you can't get a straight liability number out of it, the schedule fights you, per-location reporting doesn't exist, the front desk needs four screens to do one thing. It isn't worth paying to save a monthly fee.
If you're weighing it up, our side-by-side against Mindbody is written to be read by someone who might reasonably decide to stay, and the studio solution page lays out what the front desk, schedule and pack ledger actually look like. The same mechanics in a retail context — and the same "don't trust the consent column" rule — are in our earlier post on switching loyalty platforms without losing your data.