To change delivery aggregators without losing track of orders, move one location and channel at a time. Keep a named person watching the marketplace and kitchen during each cutover, and compare orders at the source with what reached the POS or kitchen. Do not disconnect the old route until you know what happens to orders already in progress.
The goal is a controlled handoff, not a promise that nothing can go wrong. Before setting a date, identify who can authorize each connection, what menu work must be repeated, and where staff will look if an order does not arrive as expected.
Inventory ownership before asking for a transfer
Start with your actual restaurants and marketplaces. A channel may be connected differently at two locations, even if both use the same POS. List each location separately, along with the marketplace account, current aggregator, POS, kitchen destination and fallback device or screen.
For every connection, identify the person who can sign in and approve changes. That might be an owner, a location manager or someone at the marketplace. Confirm who controls the account credentials and who receives connection alerts. A former manager's login is not a reliable migration plan.
Next, inventory the menu assets that matter to service: items, prices, modifiers, availability, hours, photos and location-specific differences. Note where the master version lives and who can edit it. Do not assume a new aggregator can import every asset or that a marketplace menu will remain unchanged when its connection changes.
Review the outgoing agreement and ask for the practical exit steps: notice period, remaining charges, cancellation procedure, account access after termination and any dependencies on the old provider. Ask when billing stops and whether access to historical records changes. Get important answers in writing; consult a qualified adviser if you need help interpreting contract terms.
The following hypothetical worksheet shows how to turn unknowns into decisions. It describes two channel connections at one restaurant, not a claim about any provider's capabilities.
| Connection | Owner and assets | Open question | Next decision |
|---|---|---|---|
| Location A, Channel 1 | Owner controls marketplace login; manager maintains menu. | Can the existing menu and modifier mapping be reused? | Manager checks the mapping with both vendors before scheduling the move. |
| Location A, Channel 2 | Manager has access; photo ownership is unclear. | Who can export or replace the photos? | Owner confirms access and replacement work before approving cutover. |
| Location A, POS and kitchen | Shift lead monitors incoming orders and kitchen output. | Where will unmatched orders appear during the handoff? | Shift lead agrees on a fallback screen and escalation contact. |
Give each unresolved item one owner and a date for the answer. If an essential question remains open, postpone that connection rather than moving every channel at once.
Verify the exact route and the work to transfer it
Ask both providers to walk through the route from marketplace to aggregator to POS or kitchen for each location. The incoming vendor should show the exact channel and POS combination you use, including any approval or setup needed. The outgoing vendor should explain how its connection is removed and what remains accessible afterward.
Separate what the providers will configure from what your staff must do. For example, a vendor may need authorization to connect an account while your manager checks item names and modifier choices. Ask who resolves a mismatch, how long setup is expected to take, and whether the marketplace must participate. Confirm whether two routes can be active at once and, if so, how duplicate orders are prevented or identified.
Ask for a demonstration of the actions that matter during a busy shift: receiving an order, displaying modifiers and totals, showing a cancellation or other supported exception, and finding an order that fails to reach the intended destination. If an exception is not supported, document the limitation and decide who will handle it manually. Do not treat an unsupported action as a passed test.
Otter describes an Order Manager that consolidates online and manual orders on a tablet, with automatic acceptance and printing and POS connections. Ask whether the exact route and exception handling fit your restaurant before comparing it with another option.
Fleksa's restaurant integrations directory distinguishes live connections from those available on request. Its US marketplace examples include DoorDash, Uber Eats and Grubhub, subject to setup and availability. Toast and Square POS connections are listed on request, so confirm your combination rather than assuming it is ready to activate. You can also review the Uber Eats integration and ask what applies to your location.
Compare the written operational quotes as well as the connection lists. Include setup, recurring software charges, any per-order charges, and the staff work needed to rebuild menus or resolve exceptions. Ask whether an overlap period adds costs. Fleksa's Fix plan includes an integration pass; see Fleksa plans for current pricing and confirm the applicable quote. Plan details were checked in November 2026. A lower software quote alone does not establish the total cost of running the route.
Simulate the route, then cut over channel by channel
Prepare a short test sheet before touching a live connection. Give each test a unique identifier and record the channel, location, item, modifier, expected total and intended POS or kitchen result. Include a normal order and the supported exceptions that could disrupt service. Use fictional details, not private customer information.
For a safe simulation, ask the vendors for a test environment or other controlled method that cannot trigger a real card charge, guest message or courier dispatch. Trace the same identifier from the source record to the POS or kitchen result. Check the item, modifiers and total at each point, then record the observed result beside the expected result. If you cannot safely simulate a route, ask the vendors for another controlled verification method before scheduling the move.
Consider a separate hypothetical test: order ID TEST-42 contains one sandwich at $12 and an added topping at $2, for a $14 item total. The expected kitchen result is one sandwich with that topping. The test excludes delivery charges, payment processing, fixed software costs and exception costs; it checks the order content, not operating cost. If the source shows $14 but the kitchen result omits the topping, the route has not passed that test. Correct the mapping and repeat the simulation.
Once the simulated checks pass, schedule a live service pilot for one location and one channel during a manageable period. A pilot handles real incoming orders, so it is different from a practice test. Assign a shift lead to watch the source channel and the receiving system, and give that person a direct escalation contact. Tell the kitchen which route is active and where to report an order that looks incomplete.
Agree on the cutover time and the treatment of orders already accepted through the old route. Do not simply switch off a tablet at the appointed minute: an earlier order may still need attention. Ask both vendors how to avoid duplicate routing and how to recognize a duplicate if one appears. If the new route behaves unexpectedly, pause further moves and use the agreed fallback while the issue is assessed.
Reconcile orders and keep a usable fallback
Choose the fallback before the pilot. It could be a marketplace screen or device that staff can access directly, if that option is available for the account. Confirm who can sign in, where the device stays, and how the kitchen receives an order handled there. The fallback owner should know when to use it and whom to call; it is not enough for a tablet to be somewhere in the building.
After each channel move, compare records for the same location and time window. Count orders at the source, then match each source order to its POS or kitchen result by order identifier. Review cancellations and other status changes separately so they are not mistaken for missing orders. Investigate duplicates and mismatched modifiers or totals as well as orders with no receiving record.
For example, if a channel shows eight source orders during the pilot, the shift lead should account for all eight individually. Seven matching kitchen records and one unmatched source order means there is an issue to investigate, even if the kitchen screen also shows eight records. The extra record could be a duplicate or belong to a different time window; the count alone does not prove either explanation.
Keep a simple transition checklist for every connection:
- Access: named account owner, authorized contacts and working fallback access.
- Assets: menu version, modifier mapping, hours and any manual rebuild work agreed.
- Route: exact channel, location, receiving system and supported exceptions confirmed.
- Checks: simulated results recorded, pilot lead assigned and reconciliation window agreed.
- Exit: in-progress orders handled, records retained as needed and outgoing cancellation confirmed.
Move the next channel only after the shift lead and owner resolve discrepancies or agree on a workable response to a documented limitation. Keep the old provider's access until you have confirmed which records and active orders still depend on it, subject to your agreement.
If you are also deciding whether to connect through a POS or middleware, the related buying guide can help frame that separate choice. Bring your channel list and test cases to a Fleksa demo, and confirm availability for each restaurant location and POS setup.
Frequently asked questions
Do I need to replace my POS to change aggregators?
Not necessarily. Ask the incoming provider to confirm the connection for your exact POS, marketplace and location, including any on-request setup or manual steps.
Can I keep the old aggregator active during the move?
Ask both vendors and the marketplace whether overlap is possible for each connection, what it costs, and how duplicate routing is prevented or identified. Keep access to in-progress orders and needed records in mind when setting the exit date.
What should I do if an order is missing after cutover?
Check the source channel and fallback immediately, alert the shift lead, and match the order identifier against the receiving system. Follow the agreed escalation process and pause further channel moves until the issue is understood.
