A POS change may require a new delivery integration, a rebuilt menu, or both. It depends on where each marketplace account, menu and order connection lives today and what the new provider supports for your location. An existing marketplace account does not necessarily mean its current connection will work with a different POS.
Before signing or setting a switch date, map each channel from the guest's order through to the kitchen. Ask the outgoing provider, incoming provider and marketplace who controls each part. Then agree on what will be transferred, recreated or handled manually.
Inventory channels, accounts and order routes
Start with a separate row for every channel at every restaurant location. Include marketplace listings, direct online ordering and any other route that sends delivery orders to your kitchen. A restaurant with two locations may have the same marketplace name on both, but different account access, menus or order routing.
For each row, record the account owner and login contact, the location or store identifier, and who can authorize a connection change. Do not put passwords in the worksheet. Record whether orders currently arrive in the POS, on a separate tablet or by another route. Note where staff accept orders and where tickets print or appear for the kitchen.
Next, follow the menu. Identify where items, prices, modifiers, availability and hours are maintained. A channel may display a menu that was originally copied from the POS but is now edited somewhere else. Ask who makes a change today and whether it appears on every channel or must be repeated.
Mark unknowns rather than guessing. If a manager cannot tell which provider owns a menu mapping, assign someone to find out before the old service is disconnected. Also record recurring trouble spots: missing modifiers, unavailable items, delayed tickets and duplicate entries. These become useful test cases, not assumptions about the new system.
Separate connections from menus and accounts
A marketplace account, a menu and a POS connection are related but separate. You might retain the marketplace account while authorizing a new connection. You might also need to rebuild some menu data or map existing items to new POS identifiers. The answer can differ by channel and location.
Ask each vendor to walk through the exact marketplace, POS and location combination you intend to use. Request a written breakdown of the work and who performs it:
- Account access: Who authorizes or removes a connection? Can the restaurant retain control of its marketplace account?
- Menu setup: Can existing items and modifiers be used, or must someone recreate or remap them? Who checks prices, hours and availability?
- Order flow: Where will a new order appear, and how does it reach the kitchen? Which actions, such as accepting an order or marking an item unavailable, are supported?
- Exceptions: What happens when an item cannot be mapped, an order is canceled or the connection is unavailable? What must staff do manually?
- Timing: Can the connection be prepared before the switch? Does the marketplace need to approve a change, and how much notice does it need?
Ask for a demonstration or written confirmation for your setup, not just a general integration list. Fleksa's restaurant integrations directory distinguishes live connections from those available on request. For example, its Uber Eats integration page is a starting point for a channel conversation, not a substitute for confirming your location and POS combination.
If your current route uses an intermediary, include that provider in the discussion. Otter describes an Order Manager that consolidates online and manual orders on a tablet, with automatic acceptance and printing and POS connections. Whether a particular connection or menu can carry over still needs to be established for your setup. For the broader choice between connection approaches, see the related buying guide.
Use a channel dependency and migration worksheet
The following is a hypothetical example for one restaurant location. The names describe staff roles, not vendor commitments. Its purpose is to show how an unknown becomes an assigned question and a decision before a channel is moved.
| Channel and current route | Dependency or unknown | Owner and next action | Decision before cutover |
|---|---|---|---|
| Marketplace A; orders reach the old POS | New connection authorization and item mapping | Manager asks both POS providers and marketplace who changes the connection and rebuilds mappings | Schedule only after responsibilities and test access are agreed |
| Marketplace B; orders arrive on a tablet | Whether a POS connection is available for this location | New provider confirms the exact channel and POS combination | Keep the tablet route if no connection is ready |
| Direct ordering; menu maintained separately | Who updates menu and sends orders to the kitchen after the POS change | Owner asks ordering provider to document the route and setup work | Approve the new route or retain a staffed manual process |
| All three channels | Who can restore a previous route and under what conditions | Shift lead obtains rollback steps and contacts from providers | Choose a fallback that staff can operate during service |
In this example, Marketplace A cannot be scheduled just because the restaurant has an account. The manager first needs an answer about authorization and mapping. Marketplace B can stay on its tablet route while the restaurant decides whether to connect it. The direct-ordering row prevents that route from being overlooked simply because the main concern is marketplaces.
Add columns or notes outside the table for your own target dates, access contacts and outstanding quotes. Ask for setup, ongoing and exception-related charges in writing, and check whether any overlap between old and new services adds to the operational total. A connection quote alone may not cover menu work, extra devices or support. Ask a qualified adviser about contract or tax treatment when needed.
Run a safe order check, then plan the cutover
Before scheduling a change, agree on a simulated or otherwise safe test with the relevant providers. The test must not charge a real card, send a guest message or dispatch a courier. If a safe test environment or method is unavailable, ask what can be verified without those effects and document the remaining risk.
Use a unique test identifier and no private customer data. In a hypothetical check, a test order contains one main item, a modifier and a special instruction. Record what should arrive at each step: the channel, the POS or other order screen, and the kitchen output. Then record what actually appears. Match the source order to the kitchen result by the identifier; check the item, modifier, instruction and order total against the source.
Also ask how to exercise supported exceptions safely. For example, can the team simulate an unavailable item or a cancellation without affecting a real order? Record the expected result, the observed result and any manual action. If a case is intentionally unsupported, list it as a limitation and decide whether the staff workaround is acceptable.
A simulation is not a live service pilot. If you later run a live pilot, choose a limited window and a channel or location, brief the staff, and agree on how real orders will be monitored and handled. Do not treat a practice order as permission to contact guests or send couriers. The live pilot needs its own operating plan and provider coordination.
Sequence the actual changes so the team can identify which route has a problem. Before each move, name a cutover owner, a person watching incoming orders and someone who can contact each provider. Set a decision time and agree on the signs that require a pause: for example, an order visible on the channel but not reaching the agreed kitchen route.
Give the rollback owner written steps and confirm whether the old connection can be restored, who must authorize it and how long that may take. If restoration is not available, choose another practical fallback, such as a staffed channel tablet if that route remains usable. Make sure staff know where to look for orders and how to prevent duplicate preparation while the issue is resolved. Keep the outgoing service in place until the agreed checks and provider dependencies are complete; overlap can help, but it does not guarantee uninterrupted service.
Bring your channel list, unresolved dependencies and safe test cases to a Fleksa POS demo. Ask the team to confirm connection availability for each restaurant location and explain the setup, testing and fallback steps for your actual channels.
Frequently asked questions
Will changing POS providers disconnect every delivery channel?
Not necessarily. A channel that operates on its own tablet may have a different dependency from one connected to the old POS. Confirm the route and authorization requirements for each location before making changes.
Will we have to rebuild our delivery menus?
Possibly. Existing marketplace accounts may remain in place while items, modifiers or mappings need work. Ask who maintains each menu and which data can be retained, transferred or must be recreated.
How can we check an integration without affecting guests?
Agree on a simulated or other safe test that uses no private customer data and cannot charge a card, message a guest or dispatch a courier. Compare the source order with the POS and kitchen results, and document any untested risks.
