Delivery-app orders can be lost during restaurant POS migration when existing connectors, item IDs, location mappings or kitchen routes still point to the old POS. Protect service by inventorying every active channel, testing the replacement with approved orders and assigning a timed cutover and rollback owner. Never disable the old receiving path before verifying the new one.
Why delivery orders go missing during POS replacement
Changing POS is more than migrating a product catalog. Each delivery marketplace may authenticate to an integration provider; that provider may connect to a specific POS account, branch identity and set of accepted events. A new POS transaction number does not preserve the old order reference unless the migration plan deliberately maps the identity.
This is a POS migration runbook for Saudi chains, not a general restaurant technology buying guide. The POS integration UAT guide describes broad test coverage; this article adds cutover sequencing, safe dual-running and rollback controls.
Diagnose migration risks before touching production
Create a dependency inventory covering every restaurant storefront, marketplace, POS location, integration account, menu catalog and kitchen output. Include independent branches operating different versions or devices. What worked at the Riyadh flagship might not work at the Jeddah satellite location.
- Source order routing: identify the external platform, aggregator or direct API that creates each POS transaction.
- Authentication: document credential owner, token expiry and environment separation, without placing passwords in shared worksheets.
- Branch identity: list old and new POS location IDs and matching marketplace storefront codes.
- Menu mappings: compare product identifiers, modifiers, taxes, fees, discount handling and availability rules.
- Kitchen output: verify printer, KDS and preparation routing connected to the new order destination.
- In-flight orders: decide how paid, accepted, preparing, cancelled and completed orders in the old system will be reconciled.
- Rollback: confirm whether provider credentials and source routing can be restored in a controlled manner; document limits.
For underlying order and menu event-mapping concepts, see the restaurant API integration guide. Assign an owner for each dependency: restaurant operations, POS vendor, integration provider, channel partner and finance. If any mandatory connection is not yet supported by the new POS, classify that as a blocker or establish a documented manual fallback before scheduling the cutover.
Step-by-step migration: stage, test, cut over and reconcile
- Freeze the migration scope. Approve the affected branches, channel list, integration version and expected behavior for each event type.
- Export reference mappings. Capture old identifiers and intended new IDs for items, modifiers, branches and sales channels. Secure the inventory of open orders.
- Configure a non-production destination. Use a supported sandbox or isolated test environment to prevent accidentally sending live customer orders into two kitchens.
- Test the transaction path. Trace a unique source order from channel confirmation to the new POS and correct kitchen device; cover difficult menu cases.
- Validate in-flight handling. Define whether pre-cutover orders remain in the old POS until fulfilled and where any cancellation or refund action is performed.
- Schedule a controlled cutover. Choose an approved lower-risk trading window, assign one coordinator and publish an explicit stop/go checklist.
- Change one receiving route at a time. Follow vendor-supported activation or credential rules; avoid unmanaged simultaneous processing.
- Monitor first live orders. Match external source references to new POS records and kitchen tickets while keeping operations, vendor support and escalation contacts available.
- Trigger rollback when thresholds fail. Stop unsafe production, preserve open-order state and restore only through the prevalidated route.
- Reconcile both systems. Compare source orders, old and new POS transactions, cancellations and completed kitchen work before closing the migration.
Dual-running should mean controlled comparison or staged parallel readiness, not sending identical payable orders to two production systems. Where shadow testing is unavailable, use separately identified approved test orders and validate on one live branch at a time.
POS migration runbook with stop/go and rollback criteria
Use the following matrix in the change meeting. Every pass requires an accountable owner and objective evidence rather than a verbal “the connector is ready.”
| Stage | Go evidence | Stop / rollback trigger |
|---|---|---|
| Entitlements | New POS and connectors authorized for exact channels | Required API license or connector unavailable |
| Mapping | Branch and item IDs approved | Unknown source-to-destination location |
| Kitchen UAT | One correct ticket per test order | Missing or doubled preparation task |
| Status workflow | Supported cancellation and order status behavior recorded | Business-critical status gap without fallback |
| In-flight ledger | Open old-system orders assigned a final owner | Unreconciled paid or accepted orders |
| Cutover smoke test | New POS receives approved live or controlled test | Confirmed source orders missing after threshold |
| Monitoring | Named incident responder and cross-system order trace | No way to identify or recover missed orders |
| Rollback readiness | Documented restoration steps tested where feasible | Old route cannot safely be re-enabled |
Define acceptance windows with the restaurant’s own operational requirements. Do not impose arbitrary universal numbers such as a fixed five-minute SLA or promise “zero downtime.” If a transaction cannot be accounted for, suspend the affected launch wave and use the contingency plan.
Hypothetical cutover across Saudi branches
Hypothetical example: a six-location group plans to replace its POS while continuing to sell through two delivery marketplaces. Four Riyadh branches migrate first; two Dammam branches follow after a stable pilot. The old POS will remain responsible for orders already accepted before the cutover timestamp.
The coordinator tests two sample transactions per participating channel and branch, including one with paid modifiers. At the first Riyadh location the new POS receives the order but prints to the wrong prep station. Operations stops the rollout at that branch, fixes kitchen routing with the POS vendor and repeats the test. Other branches remain on the existing known-good workflow until the gate passes.
The team records which orders remain in the old system and does not try to recreate them in the new one simply for cosmetic reporting consistency. That avoids unintended duplicate tickets and financial records. This is a fabricated operational example, not a real case or claim of LYNNC implementation results.
Questions for POS and integration vendors before migration
Ask each party to confirm which integration functions and historical-data operations are supported. An “open API” statement is not enough to prove a compatible migration path for your actual delivery channels.
| Question | Evidence required | Failure risk |
|---|---|---|
| Is the new POS compatible with current channels? | Named connectors, supported versions and activation steps | Channel unexpectedly disconnected |
| Can old references be reconciled? | Source ID mapping and in-flight order policy | Duplicate or missing sales records |
| What happens during brief disconnection? | Queued/rejected order handling and manual fallback | Orders silently dropped |
| Can kitchen routing be tested safely? | Authorized sandbox or test-order method | Duplicate live prep tickets |
| Can branch cutovers be phased? | Per-branch configuration and rollback procedure | Chain-wide incident |
| Who supports the cutover window? | Escalation contacts and agreed coverage | No incident owner during dinner service |
| When are old credentials retired? | Verified closure and access revocation plan | Insecure or conflicting connections |
Foodics’ integration eligibility guidance shows why account and API access should be confirmed for the existing or replacement system. This is one provider-specific source, not a guarantee about every POS. For general connector evaluation, see LYNNC’s Integrations page.
KPIs and migration acceptance checks
Order reconciliation coverage = eligible channel-confirmed orders during the migration window with a verified final order record in the designated old or new POS, divided by all eligible channel-confirmed orders in that window. The numerator must not count the same business order twice.
- Monitor unmatched source orders by marketplace and branch, with a named response owner.
- Count unintended duplicate POS transactions and kitchen tickets created during transition.
- Record POS acknowledgment delay and compare it against the approved baseline, excluding no failed orders silently.
- Track manual fallback order count and reconcile those tickets after systems recover.
- Measure post-cutover modifier, price and branch mapping exceptions separately from normal order cancellations.
- Retire obsolete credentials and connector routes after formal finance and operational sign-off.
A safe cutover is measured in controlled order identity and recoverability, not just whether the new cashier screen loads. Include a final kitchen and finance reconciliation before declaring the old environment decommissioned.
Frequently Asked Questions
Why do delivery channels go offline during POS replacement?
External channels or middleware may still use credentials, menu IDs or branch mappings associated with the old POS. The new system also needs verified kitchen routing and supported order/status flows before it can safely receive live production.
How should an operator stage test orders, dual-running and cutover?
Test in an isolated environment where possible, establish a source-order ledger and phase the change by branch. Never interpret dual-running as permission to duplicate payable orders across two live systems; reconcile in-flight orders deliberately.
What should a Saudi restaurant validate in the demo?
Require a source-to-new-POS order trace, item and modifier tests, correct kitchen handoff, a timeout scenario and a documented stop/go gate. Confirm who can change routing and who is on call during the cutover.
Which KPI proves migration did not lose orders?
Every eligible confirmed source order must reconcile to a designated old or new receiving record, with no unintended duplicate preparation. Check this by branch and channel across the actual migration window.
Decision: Migrate only when order identity, receiving route, kitchen destination and rollback ownership are proven. Request a workflow fit demo to assess the supported delivery-app connections for your planned POS transition.
