Three years of putting it off
You have known for three years that your booking system is not right. The app is clunky, fees have gone up and it does not do the reformer spot booking you need. A new system looks better, but every time you think about moving, you imagine the Monday after the switch: two hundred clients checking their balance and finding it wrong.
Some clients hold packs bought years ago with odd expiry dates. Some are on memberships with billing on different days of the month. Some have credits you gave them as goodwill. The new provider offers an import spreadsheet, and you have no idea how to fill it in correctly.
Why moving is so risky
The data that matters most is live and changing: pack balances, expiry dates, membership billing cycles and upcoming bookings. A migration has to capture them at a point in time and recreate them exactly.
Card details usually cannot simply be exported. They are held by the payment processor, and moving them requires a process between processors, or asking members to re-enter cards.
The two systems also model things differently. A pack type or membership in the old system may not have an exact twin in the new one, so someone has to decide how each maps across.
What a botched move costs
| Migration gap | What clients see |
|---|---|
| Pack balances wrong | Missing credits and angry messages |
| Expiry dates reset | Packs expiring early, or never |
| Membership billing moved | Double charges or missed payments |
| Upcoming bookings not moved | Clients arriving to classes they are not on |
| History lost | Instructors cannot see who is a regular |
The reputational cost is sharpest. Clients forgive a clunky app. They do not forgive losing classes they paid for.
How we run the switch
We treat the move as a project with checks at every stage, working with your old and new providers.
- We export everything the old system allows: clients, pack balances, memberships, bookings and history, and check the export against the live system.
- Every pack and membership type is mapped to its equivalent in the new system, with decisions on odd cases written down and agreed with you.
- Card and billing details are moved through the processors' own migration route where one exists. Where it does not, we set up a member re-registration flow with clear messages.
- We run a trial import, then compare balances, expiry dates and memberships client by client against the old system.
- On switch day, bookings are frozen briefly, final balances are exported and imported, and checks are run again before the new system opens.
- Clients get a message explaining the change, with their balance shown, and the desk has a list of anyone whose record needed a manual decision.
If your current system can be made to work with better configuration, we will say so before you commit to a move.
The odd records we look for
- Packs with no expiry, given as goodwill years ago.
- Duplicate client profiles, which are merged before the move, not after.
- Memberships on paused or frozen status.
- Aggregator and voucher bookings, which may need re-linking in the new system.
The Monday after
Clients open the new app and see the balance they expect. Memberships bill on the right day. A short list of manual cases has already been sorted. The desk answers a handful of questions, not hundreds.
- Balances and expiry dates checked client by client
- Memberships billing on the correct dates
- Upcoming bookings in place on day one
- Clients told clearly what has changed
Are you putting off a switch?
- You have outgrown your booking system but fear moving.
- Clients hold packs with many different terms.
- Memberships bill on different dates.
- Your new provider's import sheet makes no sense to you.
- You have no plan for moving card details.