The dry run every restaurant should do before switching POS
You have chosen the new POS, signed up and set a go-live date. This is the point where switchovers quietly start to fail: not because the new system is bad, but because nobody scheduled the boring part. A dry run is that boring part, and it is the cheapest insurance you can buy.
Why switchovers fail
Most problems at go-live are not in the new system. They are in the move between the old one and the new one. Three come up again and again:
- Data that maps on paper but not in service. A category, a modifier or a price was matched in a spreadsheet, and nobody rang up a real order to check it. On the first morning the kitchen screen shows something the station does not recognise.
- Connections nobody listed. The delivery tablets, the card terminal and the accounting export all still point at the old system, because they were never on the plan.
- A break in the invoice numbers. The old system’s last invoice was 34,209 and the new one starts at 1, with nothing on record to explain the jump. Tax invoices in the UAE are numbered in sequence, and a jump you cannot explain is a question you do not want at an audit.
What a dry run actually is
A dry run is not a demo. It is your team running the new system on your own menu, your own devices and your own kind of orders, for a set period, while the old system is still live. There are three ways to do it; choose by how much risk you can carry.
- Shadow run. The new POS sits on a spare device in the office. After service, a manager re-enters a sample of the day’s real orders. Nothing customer-facing changes. Cheap, and it catches most data problems. Good for a single café.
- Parallel run. For one quiet service, orders go into both systems. The customer gets the old system’s receipt; the new one records the same orders. At the end you compare the two, line by line and tender by tender. Good for most restaurants.
- Staged run. With several branches, one branch goes live first while the others stay on the old system, and the next branch follows only after a clean week. Good for groups and chains.
Five checks to pass before cutover
Whichever kind of dry run you choose, check these five things explicitly. If any of them is unclear, move the date.
- Every item rings up correctly, modifiers included. “Chicken shawarma, extra garlic, no pickles” should be one line with two modifiers and the right price, on the receipt and on the kitchen screen.
- Every item reaches the right kitchen station. Print or send a batch of real orders and walk the kitchen. Cold dishes must not land on the grill screen.
- Every outside connection is moved. Delivery platforms, card terminals and exports each need to be switched to the new system and tested with a real order or payment.
- The numbering is decided and written down. Record the old system’s last invoice number with the date and time. Start the new series either at the next number or as a new series with the reason written in your records. Decide it yourself; do not leave it to chance.
- The cash balances on day one. The cash counted at the end of the parallel run must match the new system’s cash total. If it does not, find the difference before you go any further.
The night-before rehearsal
One more step costs an evening and saves a crisis: a full rehearsal with staff, not customers, the night before go-live. Every cashier rings up ten real orders, every manager runs an end-of-shift close, and the kitchen works through a batch of tickets. The people on the floor tomorrow build the habit in a room where nothing is on fire.
This is different from general training, which shows the system in the abstract. The rehearsal is on your menu, your screens and your team. If someone gets stuck twice on the same step, that goes on the checklist.
If the dry run fails
A failed dry run is not a disaster; it is the reason you ran one. Move the date, fix the specific problem, and repeat the test until it passes. A week’s delay is cheap; a Friday night with a full room and a broken kitchen screen is not.
Write every problem down with an owner and a date to test it again. Problems without an owner have a way of coming back at the worst moment.
How we approach it at EXO NODES
When a restaurant moves to EXO NODES, we load the menu, modifiers, recipes and VAT details with the team and rehearse before go-live, starting with one location where there are several. Customer and supplier lists can be imported from spreadsheets, and we check the first Z report together after go-live.
Invoice numbers in EXO NODES are issued in sequence without gaps, per series. If you want the new series to continue from your old system’s last number, we set that up before the first sale and write down the cut-over with you, so the change of system can be explained.
This article is general information, not tax or legal advice. Rules and dates change; check the official source named in the text and speak to a registered tax agent about your own situation.
See how EXO NODES handles this.
Get the brochure for your business, or book a 30-minute live demo set up for how you work.