Before you commit to migration, be honest about why

The first question worth asking is whether the platform is genuinely wrong for you, or whether you have simply outgrown how you set it up two years ago and never revisited.

A surprising number of businesses migrate off platforms because of frustrations that could be fixed by reconfiguring the platform they are already on. Different pricing tiers, different email templates, different integrations. Before you commit to the cost and time of a migration, spend an hour with your platform's support team explaining exactly what is not working. If they can fix it, that is the cheaper answer.

If they cannot — either because the platform genuinely does not support what you need, or because the fixes require paid tiers that make the total cost untenable — then migration is the right call. But make the decision on evidence, not on impulse after a bad week.

What actually needs to migrate

Every booking migration involves the same core categories of data, and it is worth being clear on all of them before you start.

Customer records. Names, contact details, marketing preferences, any custom fields you use. This is usually the largest single dataset and the one your business runs on. Even if the platform makes export awkward, this is non-negotiable — you cannot start a new system without it.

Historic booking data. Everything the customer has booked with you in the past. This is useful for continuity ("welcome back, your last session was in March") and for reporting. Some businesses migrate the last two or three years and archive the rest.

Future bookings. Everything on the books for after the migration date. This one is critical — a customer who booked six weeks ago for next Thursday needs to still have that booking on the day. Nothing damages trust faster than a booking that disappears in a migration.

Waivers, consents, and stored preferences. Digital waivers, marketing consents, medical information, and any other stored context matter as much as the booking itself. Migrating these badly creates GDPR headaches on top of operational ones.

Financial data. Deposits held against future bookings, credits, gift vouchers, memberships in progress. These are money the customer has already paid you, held against future service delivery. Losing or misallocating any of this is a straight breach of contract.

The hardest part: your current platform's data export

Some platforms make migration easy. They provide clean data exports in standard formats, will help you take everything with you, and treat customer ownership as a right rather than a favour.

Many others make it deliberately hard. Exports are limited to specific fields. Historic data is only available in the paid tier. Waivers can only be downloaded one at a time. The subtext is that they would prefer you did not leave.

Before you commit to a migration date, actually try the export. See what fields you get. See what is missing. See how long it takes and whether it needs support engagement. This tells you what the migration is really going to involve.

The specific thing to watch for: your customers' payment methods, especially anything stored for automatic membership renewal. These almost never migrate cleanly because the underlying payment processor (Stripe, GoCardless, whoever) stores payment credentials against a specific merchant account. Migrating your business to a new payment setup means customers usually have to re-enter card details. This is inconvenient but manageable if you plan for it, catastrophic if you find out at the last minute.

The migration timeline that actually works

The fastest way to lose customers in a migration is to try to do everything on a single "cut-over" day. The safer approach is a phased migration where the new and old systems run in parallel for a period.

Weeks 8-6 before cut-over. Confirm the new system is built and ready. Do all data exports from the old platform. Import into the new system with careful validation. Set up all pricing, session types, waivers, and email templates in the new system.

Weeks 5-3 before cut-over. Run internal testing. Have staff use the new system to make test bookings, run reports, cancel and refund. Find and fix everything that does not work. Do not skip this — the day of launch is not the day to discover something is broken.

Weeks 2-1 before cut-over. Communicate to customers. Explain that you are moving to a new booking system. Reassure that all existing bookings will be honoured. Tell them what will change (they may need to re-enter payment details) and what will not (their booking history, their loyalty status, their waiver on file).

Cut-over day. Stop taking new bookings on the old system. Migrate anything that has changed since the last full export. Redirect the booking URL from the old system to the new one. Monitor closely for the first 24 hours.

Weeks 1-4 after cut-over. Keep the old system accessible in read-only mode for reference. Handle any issues that come up. Refund any duplicate bookings quickly and generously — this is the moment when goodwill matters most.

Communication with customers matters more than you think

Most migration failures are not technical failures. They are communication failures. Customers who did not know a change was happening turn up on the day expecting the old system, find it broken, and blame you rather than the migration.

The messages worth sending, in order:

  • Two weeks before: "We are moving to a new booking system on [date]. Everything you have booked with us will continue as normal. You may notice we look a little different from [date] onwards."
  • The day before: "Reminder — new system launches tomorrow. Nothing you need to do. Your bookings are safe."
  • The day of launch: "The new system is live. Any problems, [contact details]." Keep this concise. Long emails on launch day just alarm people.
  • A week after: "Thanks for bearing with us. Here is what is new/better and here is how to make the most of it."

The customers most likely to have problems are the ones who make bookings infrequently and have not seen your recent communications. Send at least one text or SMS in addition to email to catch these customers.

The things that go wrong (and how to plan for them)

No migration is completely smooth. These are the failure modes worth planning for.

A customer\'s existing booking does not appear in the new system. Almost always caused by a booking made between your export and the cut-over. Solution: keep the old system accessible in read-only mode for a month, cross-reference against complaints, and manually restore anything that fell through. Refund any duplicate bookings that resulted from the customer rebooking in confusion.

Stored payment details do not migrate. Almost inevitable. Solution: warn customers explicitly that they will need to add their payment method to the new system on their next booking. Include a clear how-to link in the launch email.

Custom pricing or discounts do not carry over. Every platform stores these differently. Solution: audit before migration, rebuild in the new system, cross-check that specific loyal customers get the same experience they used to.

Email deliverability drops for a week. New sending domain, new IP, email providers are cautious. Solution: warm the sending domain in the weeks before launch by using it for internal test emails, and monitor spam folder placement immediately after launch.

Staff resist the new system. The team is used to the old workflow. Solution: train before launch, have written documentation ready, and be visibly available in the first week to help with anything that comes up.

When to commission a bespoke system for the migration destination

If you are migrating anyway, the additional cost of going bespoke rather than to another platform is smaller than it looks. The data migration work is the same either way. The customer communication is the same either way. The only additional cost of bespoke over platform-to-platform migration is the build itself.

Which means the calculation to switch platforms and the calculation to go bespoke are often the same calculation. If you have already decided the current platform is wrong, that is the moment to seriously evaluate whether the right destination is another platform or a bespoke build.

The wrong reason to go bespoke at this moment is that you are angry at your current platform. The right reason is that you have looked at the alternatives and none of them fit either. If that is true, one migration to a bespoke system is better than two migrations — first to another platform and then to bespoke in another two years.