To protect existing bookings after a floor-plan change, first preserve a snapshot of the reservations and old table assignments. Then map each affected booking to a suitable physical table in the new layout, resolve conflicts, and check the result before hosts use it for service. Keep the original booking details intact while you change the assignment.
The important distinction is between a booking and its table number. A guest may still have a valid reservation even when the table attached to it has been removed, renumbered, or moved to a different part of the room. A host needs to know where that party can sit now, not just whether the old number still exists.
Inventory the old and new floor plans
Choose a cutover owner before changing anything. That person coordinates the floor-plan update, keeps the reference copy of existing bookings, and signs off on the host-facing assignments. Give the service manager a copy of the final seating list and a way to report conflicts.
Start with an inventory of physical tables, not just a count of guest parties. Record each table's old and new identifier, location, and usable seating capacity. Note whether it remains in place, moves, disappears, or receives a number previously used elsewhere. A table that keeps its number but moves from a quiet dining room to a busy bar area may still need a booking review.
Set capacity based on how many guests can actually be seated comfortably in the new arrangement. A four-seat table is not automatically suitable for a five-person party. Also note relevant location details, such as patio exposure, steps, or a requested accessible route. Confirm practical arrangements with the guest when needed rather than assuming the new position meets a request.
Next, capture the bookings affected by the change. For each one, preserve its booking identity, local date and time, party size, status, existing assignment, and special requests appropriate to transfer. Include bookings without an assignment: they still need capacity. Use authorized access and a supported export or other approved recordkeeping method; ask your provider what is available before relying on a particular export or import workflow.
Count bookings by service and status, then keep that count alongside the snapshot. A canceled booking should not be treated as an active party, while an active unassigned booking should not disappear from the workload. Decide how late bookings and changes made during the transition will be recorded so that the snapshot does not become stale.
Map assignments without creating new conflicts
The worksheet below is a hypothetical dinner service. Assume the bookings are active at 7:00 p.m., all parties need their own physical table at that time, and none of the tables can be combined. The capacities shown are firm limits. There are no other bookings competing for these tables during the seating period.
| Existing booking | Old assignment | New option | Decision |
|---|---|---|---|
| Party A: 4 guests | Table 12, seats 4, quiet room | Table 22, seats 4, quiet room | Assign 22; location and capacity fit. |
| Party B: 2 guests | Table 14, seats 2, main room | Table 24, seats 2, main room | Assign 24; capacity and location fit. |
| Party C: 3 guests | Table 16, seats 4, near entrance | Table 26, seats 2, near entrance | Do not assign 26; it is one seat short. |
| Party C: alternate | Same booking, no suitable mapped table | Table 28, seats 4, patio | Hold 28 as an option; confirm the patio works for the guest. |
The result is two proposed assignments and one booking requiring a decision. There are three parties, but four new physical tables listed; Table 26 remains unused. Table 28 has enough seats for Party C, yet its location differs from the old assignment. Do not mark that party as settled until the location is acceptable and the table is available for the relevant seating period.
This is a migration worksheet, not a capacity-design exercise. The goal is to find a valid destination for each existing assignment under the layout you actually plan to operate. If there is no suitable table, escalate the booking to the manager instead of forcing it into an undersized table or silently changing its status.
Check more than the arrival time. A table assigned to a later party may still be occupied by an earlier booking. Use the seating duration your restaurant plans to operate, including any planned reset time, to review overlaps. If durations vary, identify tight changes for a manager rather than treating an estimate as a guarantee that the table will be free.
Look for duplicate assignments as well. Two guests may have different booking records but still be mapped to the same physical table at overlapping times. The reverse problem also matters: a single booking should not appear twice in the host's active list just because someone created a replacement while preserving the original.
Resolve an affected booking and contact the guest
Continue with the hypothetical Party C. The booking remains active for three guests at 7:00 p.m. Its old table is no longer a suitable destination, and the proposed patio table seats four. The host or manager first checks that Table 28 is free for the intended seating period and that any relevant requests can be accommodated there.
Next, the restaurant contacts the guest through its normal approved channel to ask whether the patio location works. A useful message is specific: the reservation time and party size remain the same, but the proposed seating location is outside. Do not promise an indoor alternative until one has been identified.
If the guest agrees, update the existing booking's table assignment using the supported workflow and record the outcome for the host team. Check that the booking identity, time, party size, and active status are unchanged. If the guest declines or cannot be reached, leave a clear follow-up for the manager. Consider another suitable table or discuss available options with the guest; do not quietly treat an unconfirmed location as accepted.
Decide who is responsible for each contact and when unresolved bookings must be escalated. The host opening the service should see a concise note about the decision, not a trail of contradictory instructions. Keep guest details limited to what staff need for the reservation and handle them through the restaurant's authorized process.
Ask your reservation provider how staff can view assignment changes and booking status, and whether changing a table triggers any guest notification. Also ask how direct website bookings and Google bookings, where available, appear to hosts. The answers affect both your contact plan and your final count. Fleksa's reservations FAQ is a starting point for questions about its reservation workflow.
Rehearse safely, then reconcile the cutover
Before the first affected service, rehearse with fictional bookings in a safe environment. Confirm with the provider how to prevent a practice scenario from causing a real payment, guest message, or courier dispatch. Use fictional contact details and no real card. If the available setup cannot prevent those actions, review the workflow without submitting transactions or sending messages.
Walk through a straightforward reassignment, an undersized table, an overlapping assignment, an unassigned active booking, and a canceled booking. For each scenario, write down the expected result before acting. For example, the undersized option should be rejected by the person reviewing the plan; do not assume the software will enforce that rule. Check what staff can actually see and which steps require a manager.
A simulation is different from a live service pilot. Once the rehearsal is satisfactory, choose a real service with enough staff to monitor the changed plan. This pilot uses actual bookings and normal guest operations, so the cutover owner should be present or reachable. Give hosts the reconciled seating list, the old-to-new table map, and a clear way to flag discrepancies. Keep the previous snapshot accessible to authorized staff as a reference, not as a second live booking list.
At cutover, compare the active booking count by service and status with the reference count. Account for legitimate bookings, cancellations, and edits made since the snapshot. Then check each affected booking individually for identity, local date and time, party size, status, appropriate requests, and final assignment. A matching total alone is not enough: one missing booking and one duplicate can cancel each other out in the count.
Agree in advance on what happens if the counts or assignments do not reconcile. Pause further layout edits, identify who will correct the records, and use the reference list to manage service while the issue is resolved. Do not assume that switching layouts will prevent every interruption or preserve every assignment automatically.
When comparing software, ask for a demonstration using fictional reservations: Can staff change a floor plan without replacing booking records? How are permissions, exports, booking-channel attribution, and notifications handled? What support is available at cutover? For a broader view of related tools, see restaurant management software.
Before signing, compare written quotes for the relevant reservation setup, support, and any transition work. Check what is included and what may be charged separately. Fleksa's plans page lists its pricing; check the current terms when buying. Pricing reference checked November 2026.
Next step: Take one upcoming service and build the old-to-new table map before making a live change. Compare your requirements with Fleksa's restaurant reservation system and ask for a demonstration of the reassignment and reconciliation workflow.
Frequently asked questions
Can I simply renumber the tables and leave bookings alone?
Only after checking how the reservation system associates bookings with tables and verifying every affected assignment. A familiar number may now identify a different location or capacity.
What if there is no suitable table for an existing booking?
Keep the booking visible and escalate it to the manager. Check available alternatives and discuss any meaningful change with the guest rather than assigning a table that cannot accommodate the party.
How do I know the migration is complete?
Reconcile counts by service and status, account for changes since the snapshot, and check affected bookings individually. The cutover owner should resolve or explicitly hand off every remaining discrepancy.
