This page is only a checklist. Each item is one thing to settle first; the steps and how to write them live in the linked articles.
Steps live in this booklet; short answers in the FAQ; capability boundaries on Features; a store-type day on Store types (optional: table service / cafe & dessert / counter & snack).
Why switch, and when to keep what you have — If the current system still carries a service day, keeping it is often the steadier choice. To put a change on the table, you first need to write which step stalls, how often, and what it does to guests. A demo or a feature list is not a reason.
Test a real service day, not a demo — Your own shift staff, your menu and your equipment, through a full day. A supplier showroom, a manager doing it for them, or a verbal pass is not service evidence.
Migration: fix the scope, then run a sample — Decide which records must move, then import a sample and check counts and identifiers. Until that sample exists, “we can migrate” is not a plan.
Rollback: the trigger, who decides, how you go back — Do not stop at “if there is a problem we switch back.” Before go-live, write when you must stop, who may decide, how long the old system stays, and rehearse it with the people who will actually do it.
Hardware, training, support, full cost and data exit — Put all five on one comparison sheet. Verbal “compatible,” “we have support,” or “you can export” is not enough. Land on models, roles, hours, fees, and files you can still open after you leave.
Three conclusions only: stay, limited trial, switch when conditions are met — Do not close the comparison while key points are still unknown. The sheet allows only these three outcomes; a limited trial still needs a scope, an end date and a rollback path.
How to compare tills: not the feature list — Ticked feature lists are not enough; verify busy-day steps on one checklist in this shop.
Peak continuity: which steps to test when busy — Busy steps from open to pay must pass alone on shift; blanks stay still unknown.
Shift handoff and day-end: open tickets must not break — Open tickets still need an owner after handoff; balance day-end before the next open.
Payment exceptions: decline, interrupt, mismatch — Name the scene on the spot, who decides and what to log; clear exceptions before close.
Kitchen print: how to keep selling when tickets fail — Stop chaotic sends, set backup; do not mix reprint kinds; match tickets before handoff.
Limited trial: how to write scope, term, rollback — Write stations, shifts, features, hard dates and open rollback; at end only one of three conclusions.
Next check: Before comparing suppliers, use the restaurant software, cash-register, e-receipt, invoice and NTAK guide to separate the systems and responsibilities involved in each sale. This page does not expand those terms.
Official checkpoints. Check cash-register and e-receipt questions on the official NAV e-cash-register page, and hospitality reporting duties on the official NTAK hospitality page. Reviewed on 31 August 2026.
Related short answers
- Which venue page and which feature poster should I read?
- When should a restaurant switch POS—and when should it stay?
- What should you prepare before switching a POS?
- How do you test a POS on a real trading day—and how do you record results?
- Can “migration is possible” go into the go-live plan without a sample run?
- What must a limited POS pilot spell out—and which three end conclusions are allowed?
- What rollback items must be written before go-live—who decides, how long does the old system stay?
- Which five cost-and-exit items must be on one sheet—and are verbal “compatible / we support / we export” enough?
- How should you compare tills—why not start from the feature list?
This page is general information and a selection framework, not tax or legal advice. It does not determine which obligations apply to an individual business. It does not claim that Catering POS supports any particular workflow, device, migration route, compatibility, or regulatory function. Verify product features, supported equipment, and service terms from the documentation of the version under consideration and from your own test.