Switching booking systems without losing your regulars

This is a practical companion to our step-by-step switching guide.

You've decided the booking system needs to change. Then you think about Friday's regulars, the birthday party booked for next month and the guest who always asks for the quiet table.

The worry is understandable. Those details took your team years to learn. You don't want the move to make a familiar guest feel like a stranger.

Start with the records and the people who use them. The new booking button can wait until those are right.

Pack more than the reservation list

Before giving notice or losing access, ask your current supplier what you can export, who has permission to do it and how long the account will remain available. Check your own agreement for notice, renewal and access conditions.

Ask the new supplier to inspect a sample before you set a date. A file called “guest export” tells you very little about the columns inside it.

Records to check before switching restaurant booking systems

What to take	What to check
Upcoming reservations	Visit date, time, party size, reference, status and contact details. Include the furthest booking in the diary, not just the next few weeks.
Guest records	Contact details, useful preferences, guest identifiers and any notes your team still needs.
Marketing permissions	Consent records, their source and date where available, plus unsubscribes and other suppression records.
Booking notes and commitments	Dietary requests, accessibility needs, agreed arrangements, deposits and pre-orders. Agree separately how each will be handled.
History you need to retain	Completed visits, cancellations and no-shows, with their original status. Check what will remain a reference record and what can inform reporting.

Keep an untouched original and a working copy in an access-controlled location. Share guest files through the transfer method agreed with the supplier, rather than putting them in a public document or a staff group chat.

Ask for the right export from your current supplier

Use this as a checklist for the supplier conversation. It isn't a promise that every plan exports every field, or that the new system accepts them all.

Moving from ResDiary

Start with ResDiary's own data-export guide (ResDiary sign-in required). Ask for upcoming bookings, the guest database and marketing-permission records as separate checks.

Confirm that your date range covers the visit date, rather than only when the booking was made. Open the file and check booking references, contact details, statuses and notes. Include later bookings, such as Christmas parties, even if your first week looks complete.

Moving from OpenTable

Ask for a reservation export and a guestbook export, then check which fields and filters your account provides. Confirm that the guest list includes the permission and opt-out information you need, rather than assuming every downloaded contact is marketable.

Have your account team confirm the current export steps and access permissions. Check that cancellations and no-shows remain distinguishable from bookings your team should expect to serve.

Moving from TheFork

Ask for the bookings file and the client records needed to match it. Check whether phone numbers and email addresses are actually present in the reservation export. If they aren't, resolve the contact gap before importing.

A matching name alone isn't a reliable way to join two guest records. Ask your supplier to use stable identifiers where available and flag uncertain matches for your team to review.

Moving from SevenRooms or another platform

Ask for reservations and client records, including any exportable notes, tags and permission evidence. Check which information belongs to the individual venue and which belongs to a group.

Choose a few real examples to review securely with the new supplier: a regular guest with several visits, two people with the same name, a future party booking and a cancelled reservation. Seeing those arrive correctly is more useful than a promise to “move everything”.

Keep the details your floor team relies on

A guest name and an email address won't tell the host that someone needs step-free access or has already arranged a birthday cake.

Separate guest preferences from booking-specific requests. A note about one visit shouldn't automatically become a permanent preference. Keep internal staff notes separate from anything the new system shows to guests, and restrict sensitive information to people who need it.

Check deposits and pre-orders with the people handling payments. A note saying “deposit paid” doesn't transfer the money, a stored payment method or the ability to issue a refund. Agree which system holds that responsibility for each existing booking.

Don't assume importing old reservations recreates visit counts, spending history or customer segments either. Ask what the new reports will use, then check a sample before building campaigns around them.

Make the overlap someone's job

You can prepare the new system while the old one remains available. The important part is deciding what happens to bookings made, changed or cancelled after the first export.

Pick one person to own the handover and write down:

• Which diary controls availability at each stage.
• When the first export was taken and when the final reconciliation will happen.
• How new bookings, amendments and cancellations will be carried across.
• Which system sends confirmations, reminders and change messages.
• What the team will do if something doesn't look right.

Two unconnected booking systems mustn't both sell the same tables without a capacity plan. An overlap gives you time to check the move; it doesn't create automatic synchronisation.

Before opening the new booking link, compare future reservation counts and covers by service. Investigate differences rather than importing the same file again and hoping they disappear. Check table allocations, opening hours, turn times and party-size limits too.

If the old platform has already closed, the plan will be different. Work from the exports and access that remain available, and agree the gaps before promising a parallel run.

Check the guest journey before changing the links

Choose a quiet service for the first live day, with someone available to help your team. Give staff a short run-through using the bookings they are actually expecting.

Test your website button, social booking links, Google Business Profile and any partner listings you control. Check each separately. Updating one doesn't prove the others have changed.

Use an agreed test booking to check the time, party size, confirmation and cancellation journey. Confirm how guests will manage older reservations through the links they've already received. They shouldn't have to guess which booking page to use.

Don't send everyone a fresh confirmation simply because you've changed software. Agree which operational messages are necessary and check the wording and destination first. Keep any service update separate from promotional copy.

After the first service, ask the host what was missing. A small note that didn't come across may matter more to tomorrow's service than an impressive-looking dashboard.

Bring permissions across before bringing guests back

A software change doesn't turn a booking contact into a marketing subscriber.

For UK email and text promotions, use valid consent or make sure every condition of the customer soft opt-in applies. That includes your own similar services and an opt-out offered when collecting the details and in each message. Preserve existing opt-outs and check the evidence before sending. The ICO's electronic mail marketing guidance explains the requirements.

Once the records and permissions are checked, start with a small, relevant audience. Exclude people who have already booked or recently visited. Our win-back email templates can help with what to say.

Your regulars don't need to care which software you use. They need their booking to be there, their arrangements remembered and a welcome that feels familiar.

If you're considering nollie, bring your switching questions to a demo. We'll work through your current setup and agree what needs checking before you move.