Changing the register in a working restaurant is the most disruptive piece of software work a small operator ever does. It touches every member of staff, every shift, and the money.
It is also completely survivable if you do it in the right order and at the right time of year. Here is the order.
Decide whether you actually have to
Switching costs you a bad week even when it goes well. So the reason needs to be worth a bad week:
Good reasons. Hardware that is failing. A contract ending and renewing at a much higher price. Missing something structural — proper coursing, split checks that work, handhelds, real reporting. Being unable to get support when something breaks during service.
Bad reasons. A feature you saw in a demo and will not use. A slightly better processing rate, which is usually recovered by other fees. Annoyance at one specific thing that could be reconfigured instead.
Before you switch over a single irritation, try to fix it in what you have. A badly built menu feels like a bad POS and is not one.
Read your contract before you talk to anyone
Specifically:
- The term and the auto-renew date. Many agreements roll over silently and there is a window to give notice
- Early termination fees. Sometimes substantial
- Hardware ownership. Leased hardware usually has to go back, and a lease can outlive the software contract
- The processing agreement, which is often separate. This is the one that catches people. Cancelling the POS does not necessarily cancel the merchant account, and you can end up paying a monthly minimum on an account you no longer use
- Your data. Whether you can export sales history, customers and the menu, and in what format
Do this first, because the answers change the timetable and occasionally change the decision.
Pick the time of year deliberately
Your slowest fortnight, at least six weeks before anything you cannot afford to get wrong.
For most restaurants that means January or February, or a mid-week stretch in a shoulder season. Never December. Never the week before a holiday. Never while you are short-staffed.
Six weeks of clear air after go-live matters more than the go-live itself, because the second and third week are when the awkward cases surface — the large party, the split check nobody has tried, the month-end report that does not match.
Build the menu properly, once
This is the whole job. Everything else is logistics.
Do not import the old menu as-is. You are being handed a free opportunity to fix eight years of accumulated mess: items nobody sells, duplicate entries, modifiers in the wrong place, categories that made sense once.
Work from your actual sales report, highest-selling item first. Build each one with its real price, its tax treatment, its course, its station routing and its modifiers. Have the chef check the modifiers and a server check the ringing-in flow, because those two people find different problems.
Budget more time for this than anyone tells you. A menu of any complexity is days, not hours, and a menu built in an afternoon produces a month of small daily frustrations.
Get the money plumbing right early
Processing setup, tax rates, tip handling, service charges, gift cards and any account integration are the things that quietly fail on day one.
Tax especially. Check it against real receipts for a takeaway item, a dine-in item, and anything with a different treatment — alcohol, packaged goods, a service charge. An incorrect tax rate is a compliance problem that compounds daily and is tedious to unwind.
Gift cards and outstanding balances need a plan of their own. They are somebody's money and they cannot simply not migrate.
Train before, not during
Two sessions beats one long one.
The first is a walkthrough away from service: seat, ring, modify, course, split, tip, close. Everyone does it themselves. Watching does not count.
The second is a live-fire rehearsal — order for staff on the new system, in the kitchen, during a closed period. This finds the things nobody thought to ask about.
Pick two people who are good with it and make them the floor's first line during week one. Most questions are answerable by a colleague standing next to you, and that is much faster than support.
Run both for one service if you can
If the old system can stay up for one evening while the new one takes the load, do it. Not as a fallback you intend to use, but as a fallback that exists.
If it cannot, know exactly what you do if the new system fails at seven o'clock: paper tickets, a card reader that works standalone, and somebody who knows how to reconcile it afterwards. Write it on a card and put it by the pass.
The first fortnight
- Close out carefully every night and check the variance
- Reconcile the card batch daily until it is boring
- Read the sales report and look for items selling at the wrong price
- Keep a running list of annoyances, then fix them all in one session at the end of week two rather than fiddling nightly
- Expect to be slower. A fortnight of being slightly slower is the actual cost of switching
What to keep from the old system
Export before you lose access, not after: sales history at item level, customer records, gift card balances, and the menu as a reference. Keep the exports somewhere that is not the old vendor's cloud.
People forget this and then want last year's covers for a comparison, and last year's covers are behind a login that has been cancelled.