Switching studio software without losing members: what actually moves, and what quietly does not

Studio owners plan a software switch as a technical project and then lose members to it as a retention event. The data import is the part everyone worries about and the part vendors are good at. What actually costs members is the billing relationship: a stored card that did not travel, a membership whose renewal date shifted by nine days, a signed waiver that now exists only as a PDF nobody can search, a login that no longer works on the morning someone wanted to book.

A migration concentrates those failures into a two-week window, and they arrive disguised as ordinary attrition. A member whose card silently stopped charging does not appear as a migration defect. They appear as churn, weeks later, in a month when several things changed at once.

What follows is built on what vendors published about migration on their own pages, checked in September 2026, plus the operational sequence that gap implies. Vendor pages change, so re-read the specific claims before relying on them.

What a free migration claim actually specifies

The pattern across the platforms checked is consistent. Migration is a prominent selling point and a thin specification. Mariana Tek publishes the most detailed migration page found in this research, with a source-platform dropdown naming twelve competitors by name[1], including Momence, ClubReady, Mindbody, GloFox, Acuity Scheduling, WellnessLiving, Arketa, Wix, bsport, Hapana, Vagaro and Walla. The only substantive data-handling phrase published on it is secure migration of client data. The emphasis of the page is onboarding, weekly calls and staff training; technical data mapping is not on it.

That shape repeats. WellnessLiving lists free data migration as a line item on its pricing page[5]. Punchpass publishes free data migration support. Mangomint publishes free onboarding and data transfer. Momence's competitor comparison page lists free migration as an advantage[4] and publishes no detail on which data transfers. Every one of those claims may be entirely accurate. None of them tells you what arrives, which is the thing your front desk will find out on go-live morning.

One vendor is markedly more specific, and it is worth reading as a template for the question, not as an endorsement. Walla publishes on its Mindbody comparison page that it transfers member data, payment histories and credit cards through Stripe[2], that migration is free, and that a competitor charges for exports. It also publishes a six-week structured launch plan with a dedicated onboarding specialist. Whether or not Walla is on your list, that page shows the level of detail it is reasonable to demand: which record types, through what mechanism, and over what timeline.

Treat an unspecified migration claim as an open question, not as an absence of capability. Reply with a record-by-record list and ask the vendor to mark each line as transfers, transfers partially, or does not transfer. Get that in writing before the contract is signed, while you still have leverage.

• Member profiles: name, contact details, address, emergency contact, notes.
• Stored payment tokens for members on recurring billing.
• Active membership contracts, including start date, renewal date, price and any legacy rate.
• Unredeemed pack and class credits, with their original expiry dates.
• Visit and attendance history, at the granularity you report on.
• Signed waivers, intake forms and screening answers, with signature dates.
• Gift cards, account credits and outstanding balances.
• Communication consent state for email and SMS, with the date and source of consent.
• Staff records, permissions and pay or commission configuration.

The card token question decides the rest

Stored card credentials are not stored by your studio and usually not by your software vendor either. They live with a payment processor as tokens, and whether they can move depends on who holds them and whether both sides will cooperate on a portability request. If your outgoing platform sells its own merchant services, the tokens sit inside that vendor's payments product. If both platforms sit on the same third-party processor, portability is frequently straightforward. Walla and Punchpass both publish that their payments run through Stripe; Arketa publishes its rate as a percentage on top of Stripe fees[9]. Two platforms on the same processor is the easiest version of this problem.

The hard version is a switch between two vendors who each sell their own processing. In that case the realistic plan is that every member on auto-pay re-enters a card, and your job is to make that as close to zero-effort as possible, not to hope. Assume you will need to collect cards again until a named person at both vendors confirms in writing that tokens transfer. A sales assurance that the migration includes payment data is not the same statement, because payment history and payment credentials are different objects and the first is much easier to move than the second.

If cards must be re-entered, the mechanism matters more than the message. A link in an email converts a fraction of a membership base and the fraction is unpredictable. A card captured at the front desk during a visit converts nearly everyone who walks in. That is the whole reason a cutover should be scheduled against your busiest fortnight rather than your quietest one: you want maximum foot traffic in the window where you need a signature and a card from each member.

Extract your own copy before you sign

The strongest position in a migration is holding your own data before you have told anyone you are leaving. Export while you are a customer in good standing and while your account still has whatever tier privileges you pay for. A studio that cannot produce its own member list, waiver records and billing state without vendor cooperation is running on a single point of failure.

Note that your ability to extract is sometimes a paid feature of the plan you are on. Pike13 publishes its tier gating explicitly, with custom integrations and API access available on the top tier only[8], and digital waivers and custom terms from the mid tier upward. That is a published fact about one vendor, and the general lesson applies broadly: check what your current plan actually permits you to export before you downgrade anything, and before you give notice.

Take exports as files you can open without either vendor. CSV for tabular records, PDF for signed documents, and a written note of what each export contains and when you pulled it. Store them somewhere the studio owns, outside both platforms. Repeat the exports on cutover day, because that second copy answers a member dispute six months later about a visit predating the switch.

• Full member list with contact details and consent state, exported to CSV.
• Active membership and contract report, including renewal dates and legacy pricing.
• Outstanding pack credits and their expiry dates.
• Signed waiver and intake documents, exported as files, not as a report.
• Twelve to twenty-four months of visit history at the granularity you report on.
• Transaction and payout history, reconciled against your bank for the same period.
• A written record of what each export contains, the date pulled and who holds it.

Waivers and consent do not travel as records

Waivers are the record most likely to arrive in a form that satisfies an import and not a lawyer. A waiver's value is the binding of a specific person to a specific document version at a specific timestamp. Migrations frequently move the fact that a waiver exists, in the form of a flag on a member profile or a PDF in a document store, while losing the version reference, the signature metadata or the searchability that makes the record useful when someone asks for it two years later.

Vendors treat waivers differently enough that this is worth checking against each platform's published feature set instead of assuming. Some publish electronic waiver management as a core feature, some publish digital waivers and contracts on the pricing page, some gate custom intake forms to a top tier, and on at least one platform in this category waivers appear as an integration category rather than as a first-party feature. Ask specifically whether historical signed waivers import as documents, as records with retrievable metadata, or as a flag.

The practical decision is whether you re-collect. For most studios, re-signing the whole active base on the new platform is cleaner than arguing about whether an imported record holds up, and a migration is the one moment when asking every member to sign something is not strange. Build it into the visit: a tablet at the desk, thirty seconds, done before they walk to the floor. Pair it with the card re-entry if cards are also being re-collected, so a member does one interaction rather than two. Screening answers deserve the same treatment, because a screening response that was accurate two years ago is not evidence of anything today.

Keep the old records regardless. Export the historical waivers as files, retain them for whatever period your insurer and your jurisdiction require, and note that the new platform's records begin on the cutover date.

Membership contracts and the billing-date problem

Recurring memberships are where a migration turns into money moving in the wrong amounts on the wrong days. Three things break routinely, and all three are avoidable if you decide them in advance instead of discovering them in a reconciliation.

The first is the billing date itself. Import tools commonly set the next charge to a fixed date, to the import date, or to the start of the following cycle, and any of those can shift a member's anniversary. A member billed on the 3rd who suddenly gets charged on the 1st has been charged nine days early, and some of them will read that as an unauthorised charge and dispute it. Decide the policy before import: preserve every anniversary, or move everyone to a common date with advance notice explaining exactly what will happen and when. Both are defensible. Neither survives being decided silently.

The second is legacy pricing. Grandfathered rates live in the contract record, and an import that maps everyone onto current published plans will quietly reprice your longest-tenured members, who are precisely the ones whose cancellation costs most. Before import, produce a list of every member paying something other than the current rate and confirm each one lands correctly on the new side. Check it after import too, from the new platform's own report, not from the import log.

The third is proration and double-billing across the seam. If the old platform charges on the 1st and the new one runs its first cycle on the 5th, someone is paying twice for four days. Cancel recurring billing on the outgoing platform explicitly rather than assuming that ending the subscription stops the charges, and reconcile the first two statements from both processors line by line against your member list. Refund promptly and proactively where you find a duplicate: a refund you initiated is a service moment, and one the member had to chase is a cancellation.

Running parallel, and what parallel actually means

Running both systems side by side sounds prudent and is usually a mistake if it means taking live bookings in both. Two live booking systems against the same physical rooms means two capacity truths and a double-booked plunge on a Saturday. What you want instead is a staged cutover: the new system becomes the single source of truth for bookings on a named date, and the old system stays readable but closed for new business.

The version of parallel that is worth running is billing verification, and it happens before go-live. Import the data, then run the new platform's billing preview against your own extracted contract list and check the amounts and dates member by member for the whole active base. Not a sample. The active membership file is the one artefact where a full manual check is worth the hours, because every error in it is a member conversation.

Schedule the cutover for a period with high foot traffic and low operational stress, and freeze everything else. No pricing change, no new modality launch, no promotion, no staff turnover in the same fortnight. If something goes wrong you need to be certain it was the migration, and a month with four simultaneous changes is a month in which you learn nothing. Give staff a written script for the three questions they will actually be asked: why does the app look different, do I need to book again, and has my card changed.

Onboarding has its own timeline and sometimes its own price, which is worth confirming rather than assuming. Walla publishes onboarding as separately priced packages[3], from a free do-it-yourself tier to a paid one-time package, alongside a six-week launch plan. Pike13 describes onboarding as a customer-driven process taking a stated number of weeks. Those are the clearest published examples of setup being a distinct line from the subscription, and they are a reasonable prompt for the question you should ask every vendor: how many weeks, who does the work, and what does it cost.

The first failed charge looks exactly like churn

After cutover, the recurring billing run is the moment of truth, and its failures are silent by design. A card that did not transfer, an expired credential that the old system had already been retrying, a token that moved but now presents a different merchant descriptor the member does not recognise: each produces a failed payment, and a failed payment on a new platform without a tested dunning sequence produces nothing at all. The member is not charged, does not notice, keeps visiting for a while, and then drifts. In your reporting they are churn.

Handle the first two cycles manually. Pull the failed-payment list within twenty-four hours of each run and work it by phone and at the desk (an emailed link converts a fraction you cannot predict). Give the front desk the list every morning so a member with a failed charge is greeted by a person who already knows and can fix it in thirty seconds while they are standing there. This is unglamorous work and it is the single highest-return activity in the whole migration.

Watch for the dispute pattern too. A charge that appears under a new merchant name, on a slightly different date, for an amount a member does not recognise is a chargeback waiting to happen even when everything worked correctly. Tell members in advance what the descriptor will say and when the charge will land, in the same message that explains the switch. That one sentence prevents a category of disputes entirely.

Finally, protect your own measurement. Mark the cutover date in whatever you use to track retention, and report the following ninety days with the migration cohort flagged, so a spike in cancellations can be attributed rather than absorbed. If you cannot separate migration losses from ordinary attrition, you will draw the wrong conclusion about a pricing or programming change you made in the same quarter.

One thing that does not move in a migration, because it never lived in the platform: your listing. Praxium is a directory carrying studio profiles for city and modality searches, so a cutover does not touch it, and it is not a booking, point-of-sale or payments platform that could move any of the records above. Its optional protocol layer survives the switch for the same reason, since it describes the visit rather than reserving it.

A cutover sequence you can hand to your team

The sequence below assumes a single-location studio with an active membership base and a fixed go-live date. Adjust the timings to your own scale, and keep the ordering: everything before go-live exists to make the two weeks after go-live boring.

• Six to eight weeks out: export everything from the current platform and store it outside both systems. Confirm in writing, from both vendors, which record types transfer and whether stored card tokens are among them.
• Five weeks out: send the record-by-record list to the incoming vendor and get each line marked as transfers, partially transfers, or does not transfer. Confirm onboarding scope, duration and cost, and confirm the notice period on the outgoing contract.
• Four weeks out: run the import into a test environment. Reconcile the active membership file line by line for price, renewal date and legacy rate.
• Three weeks out: tell members. Say what changes, on what date, whether they need to do anything, what the payment descriptor will say, and when their next charge lands.
• Two weeks out: brief and rehearse with staff. Script the three questions they will be asked, and decide who owns the failed-payment list each morning.
• Go-live week: single source of truth moves. Old system becomes read-only. Card re-entry and waiver re-signature happen at the desk during visits, not by email.
• Cutover day: re-export from the old platform one final time and store it. Explicitly cancel recurring billing on the outgoing processor rather than assuming the subscription ending stops it.
• First and second billing cycles: work the failed-payment list manually within twenty-four hours of each run. Reconcile both processors line by line and refund any duplicate charge before the member finds it.
• Thirty and ninety days: report retention with the migration cohort flagged, and record which records did not survive so the boundary is documented for anyone who asks later.