Summary
A practical migration checklist for hospitality teams moving from legacy POS or EPOS systems.
Before you start: audit your current setup
Before touching the new system, document everything about your current one. List all menu items, modifiers, pricing tiers, and any special configurations (happy hour rules, discounts, staff meal policies). Note which integrations your current system has — payment processor, accounting software, reservations — and confirm which of these the new platform supports. Also audit your hardware. Identify which devices will be replaced and which may be reused. Cloud POS systems often run on standard tablets, so existing iPads or Android devices may be usable, which reduces upfront cost.
Menu build and configuration
Menu build is the most time-consuming part of any POS migration. Allocate at least three to five days for a full restaurant menu, including modifiers and dietary flags. Do not rush this phase — errors in menu configuration are the most common cause of service disruption on launch day. Build the menu in full before involving your team in training. Staff should train on a complete, accurate system, not a work-in-progress. Have a senior team member or manager review every item and modifier before the training phase begins.
Pre-migration planning
Audit current workflows, menu structure, and staff roles before migration. Identify which team members will be most affected by the change and involve them early — their feedback on the new system during configuration will catch usability issues before they become service problems. Set a clear go-live date and work backwards to create a realistic timeline. Allow buffer for menu build delays, hardware issues, and training rescheduling. A migration with a compressed timeline is one of the most common causes of a difficult launch.
Staff training approach
Train in small groups organised by role — front-of-house staff need different training from kitchen staff and managers. Focus each session on the workflows that role will use most. A server needs to know ordering, corrections, and bill handling. A kitchen team member needs to know the display system and status updates. A manager needs to know reporting, voids, and end-of-day close. Run at least two training sessions per role group before go-live. The first session covers the core workflow. The second session covers edge cases and error recovery. Teams that only receive one session tend to struggle with anything outside the standard order flow.
Launch week execution
Run staged onboarding with realistic service scenarios. Confirm reporting, permissions, and fallback processes before peak periods. On the first day of live operation, have a senior team member available at all times — ideally someone who participated in the configuration and knows the system well. Avoid launching on your busiest day of the week. If possible, go live on a Tuesday or Wednesday and use the first weekend as a more confident operation. This gives the team a few days of real service experience before facing the highest-volume period.
Post-launch stabilisation
Use first-week service data to refine workflows and team handoffs. Quick adjustments improve confidence and performance. Review the first week's data at a team meeting — look at voids, refunds, and any reports of confusion or friction. Most migration issues surface in the first five service days and can be resolved quickly if you are watching for them. Also confirm that all integrations are working correctly — payment reconciliation, accounting exports, and any third-party tools. Integrations that appear to work during testing sometimes behave differently under real service load.
What to do if things go wrong
Even well-planned migrations encounter unexpected issues. Have a documented fallback process for the most likely failure modes: POS terminal goes offline, card reader fails, kitchen display stops receiving orders. Your team should know exactly what to do in each scenario before the first live service. Keep your old system running in parallel for at least two weeks if possible. This gives you a safety net during the stabilisation period and allows you to cross-reference data if anything looks wrong in the new reporting.