The reason restaurants stay on a system they dislike is almost never the software. It is the fear of two days of chaos, a menu typed in by hand at midnight, and a Saturday where nothing works.
What comes across
Bring whatever you have. A clean export from your current system is the easiest case. A spreadsheet somebody maintains on the side works. A PDF from the printer works. A photograph of the laminated menu on the wall works — it is slower, but it works, and it is a surprisingly common starting point.
The catalogue is built for you as part of onboarding: dishes, categories, prices, option groups for size, sugar, ice and toppings, station routing, and the local-language column. That last part matters — the multilingual setup happens during migration rather than being a project you face afterwards. See who translates the menu.
What does not come across, and you should decide deliberately
Historical transactions from a different vendor’s database generally do not migrate in any useful form, and chasing them is usually wasted effort. Keep the old system’s reports as an archive — export them to a file before you cancel the account, because access often ends when the contract does.
Member balances are the one thing worth real care. If guests are holding stored value on the old system, that is money you owe them, and it needs to arrive on the new one accurately. Raise this early; it changes the sequence of the cutover.
The rehearsal is the point
Before anything is switched, we run your real menu through the whole line: take an order the way your servers will, send it to the kitchen the way your kitchen will receive it, settle it the way your cashier will. Not a generic demo — your dishes, your options, your tax setup, your printers.
That rehearsal is where the problems surface, and they always surface: a dish with a routing that makes no sense, a tax class on the wrong category, an option group that should have been mandatory, a printer that turns out to be unusual. Better on a Tuesday afternoon than on a Friday service.
The cutover
Switch between services rather than mid-shift — after close on a quieter night, or on a closing day if you have one. The old system stays available for a while as a fallback and as a reference for last month’s numbers.
Plan for staff to be slower for two or three shifts. That is normal and it is not the software. Schedule one extra person for the first busy service after the switch; it is the cheapest insurance in the whole project. See training local staff.
Confirm your hardware before the cutover date, not on it — what hardware you need.
