Why switches go wrong
Most failed migrations fail on the same three things: credit balances that do not match what members believe they have, memberships that renew twice or not at all, and saved cards that vanish so every member has to type a card again. None of these is a technology problem. They are sequencing problems, and they are avoidable.
The fourth failure is quieter: the old platform keeps charging because nobody cancelled it properly, or the export was never taken before access ended. Put the old platform's notice period and export in your plan on day one.
What moves, and how
Members and their contact details move as a list. Memberships move as re-created subscriptions that renew on each member's original date, so nobody gets a gap and nobody gets charged twice. Credit balances move as spendable credits with their real expiry dates. Visit history moves so the desk still knows its regulars. Outstanding gift cards are reissued so nothing is left owing on the old system.
Saved cards are the special case. They live with the payment processor, not the booking platform, and the only correct way to move them is a processor-to-processor migration, for example Stripe's card-migration service, where neither platform ever sees the card numbers. If a vendor tells you members will simply re-enter their cards, expect a wave of failed renewals in month one.
- Members, memberships, credit balances, visit history, gift cards
- Saved cards through the processors, never through a spreadsheet
- Schedules and products rebuilt, not imported, so the new system is set up properly
The sequence that works
Audit first. Export everything from the old platform and reconcile it: how many active members, how many credits outstanding, how many memberships and on which dates. This is the number your go-live has to match.
Build second. Configure the new system with your real formats, prices, rules and staff. Rehearse a morning rush and a refund in a sandbox until check-in feels boring. Load the data and produce a migration report that reconciles to the audit line by line.
Cut over third, on a quiet day. Freeze changes on the old platform, take the final export, load the delta, switch the booking link on your website and Instagram, and send the member email. Keep the old platform readable for a month, then cancel it in writing.
What to tell members
One email, in English and Arabic, sent in your studio's name: what is changing, what is not changing (their packs, their memberships, their prices), the new booking link, and how to sign in. Say clearly that saved cards have moved and that nobody needs to re-enter anything. Follow up on WhatsApp with the members who book most, because they are the ones who will notice first.
The desk needs a one-page script for the first week: how to check someone in, how to look up a balance, and what to say when a member insists they had one more credit. The migration report is the answer to that last one, and it should be a tap away.
Questions to ask any vendor
Who does the migration, you or me? How do saved cards move? Will memberships renew on their original dates? Will credits carry their expiry dates? Will I get a reconciliation report before go-live? Who is on the line on launch morning, and in which timezone? The answers tell you more about the vendor than any feature list.
How Bare Links does it
Our team runs the audit, the build, the rehearsal and the cutover with you, because we have done it in a real studio. Saved cards move through Stripe's migration service, memberships are recreated to renew on their original dates, credits arrive with their expiry dates, and no go-live happens until the report reconciles and your front desk signs off. The full plan is on the switching page.