You can reduce the risk of losing a service day by treating a POS change as a controlled cutover, not an installation appointment. Before switching, export the records you need, match the new setup to an approved menu, rehearse critical transactions without contacting guests or moving money, and name the person who can stop the launch.
The first live shift is part of the migration, too. Compare orders, payments, refunds and reports against authorized records before accepting the new system as your normal way of working. Keep a workable return path until that review is complete.
1. Inventory records, open business and hardware
Start with a list of what the restaurant uses today and who can retrieve it. Ask the outgoing provider how to export each record, what format it uses and how long you will retain access. Save exports securely and restrict access to staff who need them.
- Menu and prices: Categories, items, sizes, modifiers, required choices, availability, discounts and ordering-channel variations. Keep a restaurant-approved reference copy, not just whatever happens to be in the old POS.
- People and permissions: Staff names, roles, access levels and approval rules. Decide who may void an item, issue a refund or close a shift. Do not circulate passwords as part of the export.
- Transaction records: Sales reports, payment records, refunds, voids, gift card information and other records your restaurant needs to retain. Confirm how to retrieve historical detail after the switch.
- Unfinished business: Open checks, tabs, unpaid balances, scheduled orders and any outstanding refunds. Assign an owner to each item rather than assuming it will transfer.
- Physical setup: Terminals, card readers, printers, kitchen screens, cash drawers, network connections and power supplies. Note the model, location and purpose of each device.
Walk the floor and kitchen with the list. A printer that works at the counter may not be the one used for bar tickets. Ask the new provider which existing restaurant POS hardware it supports, what requires replacement and who will configure each device. Do not assume a familiar connector means a device will work.
Choose a cutover window with time on both sides. For example, close out the old system after a completed shift, then configure and check the new one before the next opening. If that gap is too short, arrange extra preparation time rather than relying on installation during a rush.
2. Map the old setup to the new one
Exporting data does not prove it is usable. Compare the approved reference menu with the new setup item by item. Check category, name, price, quantity, modifier rules and availability. A sandwich with a required bread choice needs the same required choice in the new system; a correct base price alone is not enough.
Use the worksheet below to record what must match, how to check it and who owns a correction. The owners are roles, not necessarily separate people. Add your restaurant's actual names and deadlines before rehearsal.
| Area | Acceptance check | Correction owner | If unresolved |
|---|---|---|---|
| Menu and modifiers | Compare items, required choices, availability and totals with the approved menu. | Menu manager | Correct and repeat the affected orders before launch. |
| Staff access | Confirm each role can perform assigned actions and restricted actions require approval. | Shift manager | Fix permissions and repeat the role checks. |
| Order routing | In a safe test setup, verify items reach the intended kitchen or bar destination. | Kitchen lead and installer | Fix routing or use an agreed fallback that the team has rehearsed. |
| Payments and reports | Confirm test tenders and reports can be checked against the expected results without a real charge. | Payment lead and provider | Resolve the gap before accepting live payments. |
For each exception, write down the source value, the intended new value and who approved the change. If the old menu contains a mistake, correct the reference menu deliberately; do not reproduce it simply to make the two systems match. Check that orders from each channel your restaurant uses follow the right menu and routing rules.
Ask how customer records, gift card balances and scheduled orders are handled if they matter to your operation. If a record cannot be imported, decide whether staff need a secure lookup, a manual process or another agreed solution. Assign someone to verify balances and resolve discrepancies; never assume a balance is valid just because a name appears in the new system.
Fleksa describes menu and floor preparation with onboarding guidance for its restaurant POS. Ask any provider what your team must prepare, what the provider will configure and how corrections will be checked. Also ask how the POS connects with any restaurant management software or other tools you actually use.
3. Rehearse service and set a rollback gate
Run a simulation before opening to guests. Use a test menu or designated test items, test tenders and a provider-approved test environment. The rehearsal must not charge a real card, send a guest message or dispatch a courier. Confirm those safeguards with the provider before entering a test order.
Have a server, a kitchen or bar representative and a manager follow the same steps they would use during service. Include a simple order, an order with a required modifier, a quantity change, a void requiring approval and a refund workflow. Check the displayed totals, destinations and permissions against your worksheet. Test the shift-close report as well, and confirm how simulated activity is kept out of live records.
Hypothetical rehearsal: A restaurant expects a test order with two $8 sandwiches and one $3 side. The expected item total is $19. A required bread choice should appear on each sandwich, and the kitchen test destination should receive all three items. The $19 is only an item-total check; it excludes taxes, tips, discounts and payment fees. If either bread choice is missing, the test fails even if the total is correct. Fix the modifier setup and repeat the order.
Set a named decision point before staff begin taking live orders. For example, the manager makes the go-or-no-go call after the rehearsal and before the doors open. The provider's installer and kitchen lead report their results, but one person owns the decision.
- Go: Required menu, permissions, routing, payment setup and reporting checks pass; staff know the opening procedure; and the fallback is ready.
- Delay: A failed check can be corrected and repeated within the agreed preparation window without compromising opening readiness.
- Roll back: A critical check still fails at the decision point, or the team cannot reliably take, route and account for live orders.
Write the rollback steps in advance. Confirm that the old system, its devices and access remain usable, and agree who contacts the outgoing and incoming providers if help is needed. Decide how staff will identify which system owns each order and how transactions entered during a partial cutover will be documented. Do not enter the same live order twice merely to make reports look complete.
A return to the old system is not automatic. A payment configuration, an order already started in the new system or unavailable provider access may complicate it. If rollback is not viable, agree on another practical fallback and its limits before launch, including who records orders and how the records will later be reconciled.
4. Reconcile the first live shift and accept the cutover
A successful simulation is not a live service pilot. Once the manager approves launch, the first live shift uses real orders and follows normal payment and guest procedures. Keep a manager available, record exceptions as they arise and avoid changing configuration casually in the middle of service. If a problem threatens the ability to take, route or account for orders, use the agreed stop or rollback decision rather than waiting for closing.
After the shift, compare authorized records from the POS, payment provider and any ordering channels in use. Use the same time window and note transactions that cross it. Sales, payment deposits and processing fees are different measures: a deposit may cover a different period or reflect deductions, so it should not be treated as the sales total.
- Count orders by channel and compare them with the orders staff fulfilled. Investigate missing, duplicate or canceled orders.
- Compare payment transactions with the corresponding checks, including split tenders and unpaid balances. Investigate any difference before marking a check settled.
- Review voids and refunds against manager approvals and the relevant original transactions. Confirm whether a refund was actually processed, not merely recorded as requested.
- Compare shift reports with the underlying transactions. Document timing differences, fees and deposits separately rather than forcing the figures to match.
- Review open checks, scheduled orders and outstanding balances carried across the cutover. Assign each unresolved item to an owner with a follow-up time.
Accept the migration only when the critical checks pass, the first shift has been reconciled or exceptions have an owner and an agreed resolution time, and managers can retrieve the records they need. Keep the old exports and access according to your retention needs; ask a qualified adviser about any contract, legal or tax questions. Acceptance does not mean deleting the fallback immediately. Agree when it can be retired after outstanding issues are resolved.
Ready to plan a switch? Request a Fleksa POS demo and bring your device list, approved menu, cutover window and test cases. Ask who handles each mapping, what can be simulated safely and what must happen before your team opens on the new system.
Frequently asked questions
What should I export before changing POS systems?
Export the menu, staff roles and permissions, and the historical transaction records your restaurant needs. Also document open checks, scheduled orders, balances and hardware. Confirm access and retention arrangements before the old account is closed.
Can I test payments without charging a customer?
Ask the provider for a test environment and test tenders. Confirm that the simulation cannot create a real charge, send a guest message or dispatch a courier, and verify how test activity is excluded from live records.
When should a restaurant roll back its POS migration?
Use the decision point set before launch. If a critical check fails and cannot be corrected and retested in time, or the team cannot reliably take, route and account for orders, follow the documented rollback or agreed fallback plan.
