Before you change a public ordering link, test whether a guest can build the right order, see the right total, and reach a clear confirmation—and whether your restaurant can receive and act on that order. Also name the person who can switch the link back if a critical check fails.
Keep the old ordering route available until you have verified the new one and dealt with any orders already in progress. A good-looking menu alone is not enough: service hours, modifiers, fulfillment settings, staff alerts, and links across the web can all affect the next order.
This restaurant online ordering provider migration checklist focuses on the cutover itself. For a broader look at choosing a system, read the online ordering guide.
1. Inventory the ordering journey and every public link
Start with what a guest can do today, not just the menu file you plan to import. Open the current ordering page on a phone and follow both pickup and delivery paths, if you offer them. Note what the guest sees at each step and what your staff sees when an order arrives.
Record the details that affect whether an order can be fulfilled:
- Menu and choices: items, prices, sizes, required choices, paid extras, unavailable items, and preparation notes.
- Service windows: ordering hours, pickup and delivery hours, lead times, scheduled orders, and closures or special hours.
- Fulfillment: pickup instructions, delivery areas and fees, minimums, and any handoff to a delivery provider.
- Checkout: accepted payment methods, guest-facing charges, tips, confirmation wording, and any order changes or cancellation instructions.
- Restaurant workflow: where orders appear, who accepts them, how the kitchen receives them, and whom staff calls if an order is missing.
Next, make a URL inventory. List the current address and the person who can edit each placement: your website ordering button, search and business profiles, social profiles, email templates, QR codes, printed menus, and any other place guests can start an order. A restaurant website may be the obvious starting point, but a QR code on a counter can send guests to the old page long after the website is updated.
For each placement, record whether the change is immediate, needs an outside account owner, or requires reprinting. Do not assume every link can be updated at the same time. If a printed code cannot be changed before launch, decide whether its destination can be redirected or whether the old route needs to stay usable while the material is replaced.
Finally, ask both providers what happens to orders already submitted, scheduled orders, customer confirmations, and order history after the switch. Agree on how long staff will monitor the old system. Do not close an account simply because the new button is live.
2. Rebuild representative orders and set acceptance criteria
Compare the journeys that matter to your restaurant. Include a simple pickup order, an item with required choices and paid extras, a scheduled order if offered, and a delivery order if offered. Add a service-hour boundary and an unavailable item. Someone who knows the menu should check the setup; someone who takes orders should check the receiving workflow.
Use the table as a cutover worksheet. The pass condition is the agreed behavior for your restaurant, including any intentional changes. Record the result and owner in your own working copy; a failed critical check means the public link stays where it is until the issue is fixed and retested.
| Check | Pass condition | If it fails |
|---|---|---|
| Menu and modifiers | Required choices, prices, extras, and unavailable items match the approved menu. | Correct the setup and repeat the affected order. |
| Hours and fulfillment | Pickup or delivery is offered only for the intended times and locations. | Fix the rules; keep the old link until a boundary check passes. |
| Checkout and confirmation | Itemized charges and order details match the agreed setup; the next step is clear. | Resolve the discrepancy and repeat the checkout simulation. |
| Restaurant handoff | Staff can identify the simulated order and follow the agreed acceptance and kitchen workflow. | Fix routing or staff instructions and repeat the handoff check. |
| Public link and fallback | The intended link opens on mobile; the owner can restore the old destination. | Do not cut over, or restore the old destination if already live. |
Use a safe simulation or provider-supported test mode for these checks. Confirm in advance that it cannot charge a real card, send a guest message, or dispatch a courier. Use clearly marked test details and tell staff not to prepare simulated food. If the provider cannot simulate a particular step, ask for a demonstration and agree on a safe way to verify it before making a customer-facing promise.
Here is a hypothetical pickup comparison. A guest chooses a $12 bowl and a $2 extra. The expected item subtotal is $14. With an illustrative $1 service fee and a $2 tip, the displayed total should be $17 before any applicable tax. This example includes those item, fee, and tip amounts; it excludes delivery and any other charge. Check that the choices, each line, and the final total appear as intended in the simulation. It is an arithmetic check, not a prediction of any provider's fees.
Then follow the order beyond the guest screen. Can the staff member responsible recognize the order, its pickup time, and the paid extra? Does the kitchen get the information it needs in the agreed format? Ask the provider how rejected orders, changed availability, and interrupted connections are handled. Write down the answer and the staff action, rather than assuming a notification or integration will work in every setup.
3. Set the cutover decision and rollback plan
Choose one decision owner for launch and rollback. That person needs access to the link controls, a way to contact the provider, and authority to pause the switch. Name a backup in case the owner is unavailable. Assign separate people to update placements, watch incoming orders, and communicate with the shift team; one person may cover more than one role in a small restaurant.
Pick a quiet period with enough staff and support available. Work backward from the next service rush to establish the last safe switch time: the latest point at which you can change the main link, complete the live checks, and still restore the old link before that rush. Allow time for each public placement to update and for staff to confirm which systems they must watch. If that time arrives and a critical check is unresolved, postpone.
Write a short go/no-go record before the switch:
- List the critical checks that must pass, including the guest journey, order handoff, and restoration of the old link.
- Record the new and old destinations, where each is controlled, and who has access. Avoid putting passwords in the shared checklist.
- Confirm how scheduled and in-progress orders will be handled and who watches the old system.
- Set a rollback trigger, such as a broken ordering link or an order handoff that staff cannot reliably use.
- Set a check-in time and identify the owner who declares the cutover complete or orders a rollback.
Rollback is more than changing one button. The owner should identify which links have already changed, restore the destinations they control, and tell staff which system is active. Continue watching both systems for orders that may already have been started or submitted. Ask each provider how to handle any such orders; do not assume that reversing a link moves them between systems.
Keep a contact list and a plain-language staff instruction near the order station: which screen to monitor, who accepts orders, what to do if details are unclear, and whom to call. Brief the next shift as well as the team working at launch. A handoff that exists only in the manager's head is easy to miss.
4. Verify the public paths and monitor the first service
After changing a link, open the actual public placement on a phone rather than relying on an administrator preview. Check the website button and each other updated placement. Confirm that the destination is the intended new ordering page and that the restaurant name, menu, and service status make sense. If a link still shows the old destination, record it and check again; do not mark the placement complete just because the edit was saved.
On mobile, walk through pickup and delivery where available: select representative items, check required choices, enter the relevant fulfillment details, and review the total. Stop before any action that could create a real order, payment, message, or courier dispatch. Use the safe simulation agreed with the provider for submission and handoff checks. A live public-path check and a simulated order check answer different questions: one verifies the link guests see; the other verifies the workflow without creating real-world consequences.
During the first live service, assign someone to watch the new order channel and the old one for the agreed transition period. Compare incoming order details with what staff needs to prepare and hand off food. If a real guest reports trouble, follow your normal service process and document the issue for the decision owner. Do not invent a practice guest or send a practice order into the live workflow.
At the planned check-in, review unresolved link changes, staff reports, and any orders still pending in the old system. If a rollback trigger has occurred, the owner should act on the written plan rather than waiting for the next rush. If the critical checks pass, keep the inventory until every remaining printed or digital placement has been addressed and the old-order monitoring period has ended.
Next step: Put the URL inventory and acceptance checks in a shared sheet, name your cutover owner, and schedule the simulations before choosing a switch time. If you are evaluating Fleksa, review its restaurant online ordering page and ask for a demonstration of the order and handoff checks that matter to your restaurant.
Frequently asked questions
Should I turn off the old ordering system when the new link goes live?
Not automatically. Agree with the old provider on how to handle submitted and scheduled orders, and keep staff monitoring the old route for the transition period you set. Close it only after those responsibilities are resolved.
How can I test without charging a card or dispatching a driver?
Ask for a safe simulation or provider-supported test mode and confirm that it cannot cause a real payment, guest message, or courier dispatch. If a step cannot be simulated, ask the provider to demonstrate it and agree on another safe verification method.
What should cause us to delay or reverse the switch?
Delay or roll back when a critical acceptance check fails—for example, the public link is broken, the total is wrong, or staff cannot reliably receive order details. The named decision owner should follow the recorded rollback plan and tell the team which system to watch.
