The short version
Treat the guest list, historical visits and future reservations as separate parts of the move. Review a sample export, agree what can transfer and reconcile every future booking before switching the public booking link.
Before switching reservation software, check that your team will have the records and booking commitments it needs for the first service in the new system. A clear transfer plan covers both the files and the way your restaurant will use them.
If you are evaluating a move from OpenTable, Resy, Tock or Libro, use this checklist to make the migration conversation concrete. Export access, fields and transfer options vary by provider and account.
Download the one-page checklist
1. List what actually needs to move
On a small screen, swipe to see all columns.
| Information | What to check |
|---|---|
| Guest list | Names, contact details, notes, tags and recorded communication preferences |
| Past bookings | Dates, times, party sizes and outcomes, including cancellations and no-shows |
| Future reservations | Each upcoming booking and its status, including bookings awaiting guest confirmation, plus seating needs and contact details |
| Restaurant setup | Tables, hours, booking rules, messages and team access |
| Payments or experiences | Deposits, payment references, refund handling and any prepaid arrangements |
A guest directory does not necessarily contain visit history. Past-booking history does not recreate the future reservations you still need to honor. A contact list also does not recreate a floor plan or booking policy.
2. Request the right exports while you have access
Ask your current provider which guest and reservation exports your account can obtain. Confirm whether the export includes the whole date range or only a filtered report.
Request the full guest directory and review reservation history separately. A marketing-contact export may contain only a selection of guests, so confirm which file you received and whether filters were applied.
Confirm the current export route, account permissions and available fields with your provider. Check the file itself rather than relying on a screenshot of a menu from a different plan or an older account.
Export request to adapt
Please confirm how we can export our guest directory, historical reservation outcomes and all future reservations. We need the available names, contact details, notes, tags, communication preferences, booking dates and times, party sizes and statuses. Please tell us which fields or dates are excluded.
Keep the original files unchanged and record the export date. Share them through the transfer method agreed with the migration team, rather than posting real guest rows into a public discussion.
3. Review a sample before agreeing to the whole move
Choose a small, representative sample: a returning guest, someone with only one contact method, a cancelled booking and a no-show. If you have multilingual names or notes, include them in the review too.
- Do names and phone numbers still match the source?
- Are dates interpreted correctly? Does 04/05 mean April 5 or May 4 in this file?
- Do service times still match the restaurant’s local time?
- Are statuses, notes and tags preserved or clearly marked as excluded?
- Are opt-outs and unknown communication preferences kept distinct?
Keep any recorded preferences attached to their source. Moving a contact into a new system should not automatically change an unknown preference into an opt-in.
When evaluating yourturn, ask the team to review the actual file and confirm the available import workflow before you plan around it. Provider names alone do not establish that every version of their exports transfers without adjustments.
4. Reconcile every future reservation
Make a separate list of upcoming commitments. Check booking date and time, party size, guest contact, notes and seating requirements against the plan in the new system.
Agree how future bookings will be recreated or handled before changing systems. Guest and past-visit imports in yourturn do not recreate active future reservations; discuss those bookings separately with the team.
Also agree what happens to guests’ existing confirmation and cancellation links. They may still point to the old provider, so keep a clear route for guests to contact you during the handover.
A guest-data file does not move card credentials, prepaid funds or refund handling into a new platform. If those are part of your workflow, confirm the arrangements with the relevant providers before ending the old service.
5. Plan one clear handover
Pick a quiet point between services and name the person responsible for the switch. Define when new online bookings stop entering the old system and start entering the new one.
After the last export, review any bookings or changes made since it was taken. Reconcile those updates before opening new availability; a file from yesterday is not automatically the current reservation book.
- Review the new hours, tables, party-size rules and staff access.
- Reconcile the upcoming booking list and agree how existing messages will be handled.
- Change the links on your website, Instagram and other places you control.
- Open each link on a phone and check the guest path without submitting an unnecessary reservation.
- Brief the host team on the first service and how to handle guests with an old confirmation.
Keep access to the records you still need for reconciliation and agreed payment handling. Confirm the wind-down arrangements with the old provider rather than treating a changed bio link as the end of the migration.
6. Ask these questions in a demo
- Which fields from my actual export can be brought over?
- Which records need review or manual handling?
- How will we deal with future bookings and seating conflicts?
- What happens to guest preferences, existing links and messages?
- Who owns each part of the handover, and when will we review it?
A useful demo should make those answers specific to your restaurant. Bring your requirements and export field names; arrange a suitable transfer route before sharing real guest data.