A POS switch is not a screen replacement. It changes how orders, money, people, devices, and operational memory move through the restaurant. Treat it like an operating change, not an install.
Ask vendors to show the workflow, state the limitation, and explain who owns recovery. A clear “not yet” is more useful than a vague “yes.”
1. Inventory the current operation
List every location, service model, revenue center, menu, order channel, tender, device, printer route, integration, report, employee role, and closeout process in use today. Include the workaround no one documented.
2. Classify the data
Separate data that must migrate, data that can remain in an archive, and data that can be rebuilt. Confirm ownership and exportability of catalog, customers, gift cards, inventory, employees, orders, payments, and reporting history.
3. Map workflows, not just features
Document the start state, actors, decisions, permissions, failure states, and final record for your most important workflows. A refund, table transfer, item 86, pickup, or server close can expose gaps that a checkbox cannot.
4. Validate the physical environment
Confirm every register, reader, printer, kitchen display, cash drawer, scanner, network segment, power location, mount, and fallback process in the venue—not only in a lab.
5. Rehearse real scenarios
Run ordinary service, the busiest service, and failure scenarios with the people who will own them. Include menu edits, voids, payment exceptions, connectivity changes, printer issues, and closeout.
6. Define launch and rollback
Write down the launch scope, who can make which decisions, what stops a launch, and what triggers rollback. “We will figure it out that day” is not a plan.
7. Preserve the old record
Agree on how historical access remains available, how teams retrieve prior receipts and reports, and who owns the archive.
Request a Trellis demo and bring the scenarios that matter most to your restaurant.