Field notes

Switching off Tripleseat: a migration checklist for restaurant groups

What to export, what to clean, and how to change event systems between peak seasons — without losing a booking.

Changing event systems feels risky because the pipeline never sleeps. There is always a tasting next week, a wedding next month, and a December that is already half sold. So groups stay on software they have outgrown — not because it is good, but because the move looks dangerous.

It does not have to be. A migration is a checklist, not a leap. This is the checklist we walk restaurant groups through, whether they move to Excellent or to anything else.

Why do restaurant groups leave their event platform?

Three reasons come up again and again:

  1. The group outgrew single-location thinking. The software manages one room well, but the director of events runs six. Pipeline reviews become six logins and a spreadsheet.
  2. The team stopped using it. Managers quote from memory and reconcile later because the tool is slow on a phone, or slower than a text message. The system of record quietly stops being the record.
  3. The guest experience lags the room. A group that sets a beautiful table sends a proposal that looks like a form from 2009. Guests notice.

If none of these describe you, keep what you have. Migration is only worth it when the daily cost of staying is real.

When is the right time to switch event systems?

Between your peak seasons, with a four to six week window. For most US restaurant groups that means late January to early March, or the middle of summer. Never move in the fourth quarter — December bookings are made in October and November, and you want one system of record while they land.

Pick a cutover date first. Every other step on this page counts backward from it.

What should you export before you cancel?

Export everything below while your account is still active. Exports are easy to run today and painful to beg for after you cancel.

  • Future events — every tentative, definite, and closed booking from today forward. This is the one list you cannot lose.
  • Past events, two years back — enough history to answer "what did we charge them last year?" without keeping the old system alive.
  • Contacts and accounts — hosts, planners, and the companies they book for, with emails and phone numbers.
  • Documents — signed contracts and BEOs as PDFs. Signed paper belongs to the booking, not to the software it was signed in.
  • Menus and packages — names, items, and prices. You will rebuild these, so a clean list is enough.
  • Payment history — deposits and balances per event, so the new system starts with true numbers.
  • Lead sources — where your inquiries actually come from. You will want this when you rebuild your lead forms.

One honest note: every platform exports differently, and some exports are partial. Check the row counts against what you see on screen before you trust a file.

How do you clean the data before import?

Do the cleaning in the spreadsheet, before anything touches the new system. Thirty minutes here saves weeks of "which Sarah is this?" later.

  • Merge duplicate contacts. Sort by email, then by phone. Keep one row per human.
  • Map your spaces. List every room and private dining space per location, with capacities. Old systems accumulate ghost rooms — retire them now.
  • Collapse statuses. If the old system has nine event statuses and your team really uses four, migrate four.
  • Archive dead leads. An inquiry from 2023 that never answered is history, not pipeline.
  • Decide the history horizon. Two years of past events is usually enough. Keep older exports in cold storage.

How do you run the cutover without losing a booking?

  1. Import in order: spaces, menus, contacts, then events. Each layer references the one before it.
  2. Load future events first and verify them by hand. Print the calendar from both systems and compare, location by location. This is the hour that matters most.
  3. Run one parallel week. New inquiries go into the new system; existing bookings are updated in both. One week — longer and the double entry breeds errors.
  4. Make the old system read-only on cutover day. Announce it plainly: "From Monday, if it is not in the new system, it does not exist."
  5. Repoint your lead forms — website, Google Business Profile, OpenTable notes, the events@ inbox autoresponder. Leads follow the forms, not the software.
  6. Keep the old account alive, read-only, for one billing cycle. It is your safety net, not your workspace.

What should the first week on the new system look like?

Small and real. Have every sales manager build one genuine event end to end — inquiry, proposal, contract, deposit, BEO — in the first two days. Review the output together: does the proposal read like your rooms feel? Does the BEO say what the kitchen needs? Fix the templates while attention is high. A system your team shapes in week one is a system they defend in month six.

The checklist

  1. Pick a cutover date between peak seasons.
  2. Export future events, two years of history, contacts, documents, menus, and payment records — while the account is active.
  3. Verify export row counts against the screen.
  4. Merge duplicate contacts; retire ghost spaces; collapse unused statuses.
  5. Import spaces, menus, contacts, then events — in that order.
  6. Hand-verify the future calendar in both systems.
  7. Run one parallel week.
  8. Make the old system read-only; repoint every lead form.
  9. Have each manager build one real event in week one.
  10. Keep the old account read-only for one billing cycle, then close it.

Excellent was built for exactly this move: its importers read the spreadsheets and PDFs other systems export, and a human reviews every row before it lands. See how Excellent and Tripleseat compare, read how the whole flow works, or watch the three-minute demo.