POS migration without losing a Saturday

The new point of sale arrives on a Thursday. The owner wants it running for the weekend, so the menu is entered on Friday afternoon, the staff get a ten-minute demonstration before Saturday's service, and the old system is switched off. By eight o'clock on Saturday, servers cannot find half the dishes, the kitchen tickets are missing their changes, a split bill takes five minutes and the manager is taking orders on paper.

Most failed switches fail for the same reasons: too little time, too little training and the wrong night. A POS migration is a project of about three weeks, not a weekend, and the busiest night of the week is the worst possible time to learn a new system.

This guide sets out a POS migration plan over three weeks: what data to bring across, how to rebuild the menu, how to train the team, how to run a short parallel test, and how to choose the night to switch. Every venue and figure in it is an example.

Switches go wrong when they are rushed. The old system's contract ends, the new one is bought, and the change is squeezed into the days between. The menu is entered in a hurry, with mistakes. Staff learn on the job, during service. Nobody tests the kitchen tickets, the split bills or the end-of-night figures until they are needed.

They also go wrong when the old system is switched off too soon, so there is nothing to fall back on, or when nobody owns the project, so tasks fall between people.

A good POS migration gives each part its own time: data, menu, setup, training, testing and the changeover itself.

The first week is for decisions and gathering. Choose a switch date, a quiet night, at least three weeks away. Name one person who owns the project and has the time to do it.

Gather what you will need from the legacy POS: the current menu with prices, options and allergens; the list of staff and their roles; the table layout; the payment methods you accept; and any guest records you hold. Export the old system's reports for the past year or two, because they are the history you will compare against.

List everything the old system does that you rely on, including the small things: a particular report, a way of splitting bills, a printed receipt format. Check the new system handles each one, or decide how you will work without it.

Not all POS data needs to move, and not all of it can. Decide what matters. The menu, the staff and the table layout must be set up in the new system. Guest records, if you hold them, are often worth bringing. Past sales usually stay behind, in reports exported from the old system.

Check what the new system can import and in what form. Some data comes across from a spreadsheet; some must be entered by hand. Ask the provider, and test an import with a small sample before relying on it.

Treat the move as a chance to clean up. Dishes nobody has ordered for months, staff who left last year and guest records with no contact details can stay behind. The idea is the same as any data migration: move what is useful, check it arrived correctly and keep the original until you are sure.

A POS migration often affects more than the till. Card terminals, accounting software, booking systems, delivery platforms, payroll and any loyalty scheme may all connect to the old POS. Each connection must be rebuilt, replaced or retired.

List every connection in week one, with what it does and who depends on it. Check which ones the new system supports, set them up in week two and test them in week three. A connection forgotten until after the switch, such as the export your accountant relies on, can leave a gap in the books that takes weeks to fill.

Past sales rarely move across in a POS migration, but the history still matters: for comparing this year with last, for the accounts and for any questions from the tax authorities. Export the reports you will need, in a form you can open without the old system, such as spreadsheets or PDFs, and store them safely.

Check the exports before the old system is switched off. A report that will not open, or is missing a month, is easier to fix while the old system still runs.

The menu is the largest single job in most migrations, and the one where mistakes cost most. Every dish needs its name, price, category, options, removals, allergens and the station that cooks it. A wrong price charges guests wrongly; a missing allergen is a risk; a dish sent to the wrong station never reaches the cook who makes it.

Build the menu in the new system carefully, then check it against the old one, dish by dish. Have the head chef check every allergen and every station. Have a manager check every price.

Good menu management in the new system starts here. A menu built cleanly, with options set up properly rather than typed as notes, saves time in every service afterwards. Our guide to menu management when you run four venues covers keeping it in order as the venue grows.

Next come the tables, the staff and the devices. Draw the table layout to match the real room, with the right table numbers. Set up every member of staff with the right role and permissions. Set up the payment methods.

Install and test every device: tills, tablets, handhelds and kitchen screens. Check that each one connects reliably, and that the wifi reaches every part of the floor where a device will be used. Check the card terminals work alongside the new system.

Test the kitchen tickets for every station. Send test orders with options, removals, allergies and held courses, and check that each station receives exactly what it should.

The second week is for POS training. Every member of staff should be trained before their first shift on the new system, not during it. Plan short sessions, by role: servers, bartenders, kitchen and managers each need different things.

Servers need to ring in orders with changes, open and find checks, hold and fire courses, split, move and close checks, and record payments. The kitchen needs to read the new tickets and clear them. Managers need voids, comps, refunds, reports and the end-of-night routine.

Practise with real orders from your own menu, including the hardest ones: a table of eight with allergies and changes, a bill split four ways, a table that moves to the bar. Our guide to staff training that fits around service covers how to fit training into a working week.

Some staff dislike new systems, often because they have learned the old one well and fear looking slow in front of guests. Their concerns are reasonable, and they deserve attention rather than impatience.

Involve them early. Ask experienced staff to help test the system and point out problems before the switch. Give extra practice to anyone who wants it. Pair less confident staff with someone who has picked it up quickly.

Make it clear that the first few services will be slower, and that this is expected. Staff who know mistakes will be forgiven learn faster than those who fear them.

Before the switch, test the whole day, not just the ordering. Open the system as the opening team would. Run a mock service with real orders, real changes and real split bills. Close the day as the closing team would, and check that the figures make sense.

Check the reports. Do the takings add up? Do voids and comps appear correctly? Can the manager find what they need the next morning?

Fix whatever the test reveals, then test again. A problem found in a mock service costs nothing; the same problem found on a busy night costs a great deal.

In the third week, run the new system alongside the old one for a service or two, if you can. Some venues run the new system for lunch while dinner stays on the old one; others put one section of the room on the new system for a quiet evening.

A short parallel run shows how the system behaves in real service, with real guests, while the old system is still there if something goes wrong. Keep it short: running two systems for long doubles the work and the chance of mistakes.

Compare the results: did orders reach the kitchen correctly, did payments match, did the end-of-night figures agree?

Choose the quietest night you can for the full switch, never a Friday or a Saturday. Early in the week is usually best: the team has time to settle in before the weekend, and any problems can be fixed before the busiest nights.

Avoid dates near holidays, large bookings, events or menu changes. One change at a time is enough.

Make sure the project owner and someone who knows the new system well are on site for the first few services, and that the provider's support is available at those times.

A short checklist keeps a POS migration on track:

Tick each item off as it is done, and do not switch until every item before the switch night is complete.

Guests rarely notice a POS migration if it goes well, but a few things may change: the look of the receipt, the way a bill is split or the name that appears on a card statement. Brief the team so they can explain any change calmly.

Tell suppliers and partners whose systems connect to yours, such as a booking platform or a delivery service, when the switch will happen, so they can test their side. If your booking links, QR codes or online menus change with the new system, update them everywhere guests find them: your website, your listings, social media and printed materials.

On the night of the switch, keep the old system available but out of the way, in case it is needed for reference. Have a paper fallback ready: order pads, a printed menu with prices and a way to record payments.

Brief the team before service: what to do if something goes wrong, who to ask, and that slower service is expected tonight. Watch the kitchen tickets closely in the first hour, and check the first few split bills and payments.

After service, check the figures, note any problems and fix them before the next service. A short meeting the next day, with the team's feedback, catches problems the managers did not see.

The first two weeks after the switch are when staff settle in and the last problems appear. Keep a list of issues as they come up, and work through it. Some will be setup problems, such as a dish on the wrong station; some will be training, such as a server who never learned to split a bill.

Keep supporting staff who find the change hard. Most will be comfortable within a week or two; a few will need more help.

Do not cancel the old system's contract until you are sure you no longer need it, and keep its exported reports for as long as you need the history.

A POS migration costs more than the new system's price. Staff time for training, an overlap of subscriptions while both systems run, new hardware, cabling or wifi improvements, and the time the project owner spends on it all add up.

Budget for them in advance, so the switch is not rushed to save a week's subscription. Our guide to how much does a POS cost in the first year covers the costs of the new system itself.

After a month, compare the new system's figures with the old system's reports for the same period last year: sales, covers, average spend, voids and comps. Large differences may point to setup problems, such as a price entered wrongly, or to real changes in how the venue is trading.

Ask the team how the new system compares: what is faster, what is slower and what is still awkward. Their answers point to the last setup changes and training gaps.

A migration is finished when the team no longer thinks about the system during service.

Leaving a legacy POS can leave loose ends: a server in the back office, terminals that need disposing of, a support contract with a notice period and data that should be kept or securely deleted.

Check the old contract's notice period early, in week one, so you are not paying for two systems for longer than necessary. Keep the old data you need for reports, accounts and legal records, and delete the rest securely, especially guest and payment data.

Dispose of old hardware properly, after removing any stored data.

Sometimes the right decision is to delay. If the menu is not finished, the staff are not trained, the test revealed problems that are not yet fixed or the switch date has drifted into a busy week, move the date.

A delay of a week costs little: another week on the old system. A switch made before the venue is ready can cost a weekend of trade, the team's confidence and guests' goodwill. Set the date, but let readiness decide it.

An invented bistro plans its POS migration over three weeks. In week one, it chooses a switch date on a quiet Tuesday, exports two years of reports from its legacy POS and gathers the menu, staff list, table layout and guest list. In week two, it builds the menu and has the head chef check every allergen and station, sets up the tables and devices, imports its guest list from a spreadsheet and trains every member of staff in short sessions by role.

In week three, it runs the new system for two quiet lunches while dinner stays on the old one, fixes three setup problems and runs a mock close. On the Tuesday, it switches fully, with the project owner and an experienced user on site and a paper fallback ready.

The first service is a little slower than usual and nothing goes seriously wrong. By the weekend, the team is comfortable, and the Saturday is the busiest of the month.

Moving to servearound starts with the menu: dishes, categories, prices, photographs, options, allergens, dietary tags and each dish's station are set up in servearound's menu editor, and a menu built at one venue can be copied to the others. Guests can be brought across from an Excel or CSV file using servearound's template, after confirming the list is of guests who visited or booked, and imported guests are not signed up to marketing emails. Past sales from the old system do not come across, so keep its reports for comparison.

Team members are invited with their roles and sign in on shared screens with a four-digit PIN, the floor plan is drawn in the designer to match the room, and kitchen screens, host stands and tills pair with the venue using the short code each one shows. To plan a switch, see pricing or get in touch.

About three weeks: one to decide and gather, one to build and train, and one to test and switch.

The menu, staff and tables must be set up; guest records are often worth bringing; past sales usually stay in exported reports.

On the quietest night you can, early in the week, never on a Friday or a Saturday.

Before their first shift, in short sessions by role, with real orders from your own menu.

Briefly, for a service or two, to test the new one in real service while the old one is still there.

Have a paper fallback ready, and someone who knows the new system on site.

When you are sure you no longer need it, and after exporting the reports and data you need to keep.

The figures compare sensibly with last year, the team's list of problems is empty and nobody thinks about the system during service.

A POS migration is a project of about three weeks, not a weekend. In week one, choose a quiet switch date, name an owner, gather the menu, staff, tables and guests, and export the old system's reports. In week two, build the menu carefully, check every price, allergen and station, set up the devices and train every member of staff before their first shift.

In week three, run a short parallel test and a mock close, then switch on a quiet night early in the week, with a paper fallback and an experienced user on site. Keep supporting the team through the first fortnight, compare the figures after a month, and close the old contract only when you no longer need it.