Switching systems: the fear and the actual risk

Ask a restaurant owner why they are still using a till they dislike and the answer is often fear. Fear of losing the guest list built over years. Fear of a Saturday night when nothing works. Fear of staff who will refuse to learn something new. Fear of a contract that turns out to be impossible to leave. So the old system stays, with all its costs, because the switch feels riskier than the problem.

Some of those fears are justified, and some are much larger in the imagination than in practice. Switching systems does carry real risks, but they are specific, they can be named in advance and most of them can be managed with a plan. The venues that switch badly usually skipped the plan, not the software.

This guide sets the common fears against the actual risks, explains what genuinely goes wrong in a switch and lists the four things to insist on before you start. Every venue and figure in it is an example.

Owners fear switching because the till and the booking system sit at the centre of every service. If they fail, guests wait, orders go missing and the night falls apart in front of everyone. The cost of a bad switch is visible and immediate; the cost of staying with a poor system is spread thinly across every day, and easy to ignore.

That imbalance keeps venues on systems that cost them money and time for years. Naming the real risks, and how to manage each one, is the first step to deciding clearly.

The first fear is losing the guest list: years of names, preferences, allergies and visit histories. It is a real risk if the old system cannot export guests, or exports them in a form the new system cannot read.

The actual risk depends on two things you can check before you start: can the old system export the guest list, and can the new one import it? Ask both suppliers, ask for a sample export and try it. Our guide to owning your guest data when you switch systems covers how to protect it.

The second fear is the first service on the new system going badly: the till freezes, orders do not reach the kitchen, the team does not know what to do. It happens, but almost always for reasons that could have been prevented: no testing, no training, a busy night chosen for the switch.

The actual risk is small when the system has been set up and tested in advance, the team has practised and the switch happens on a quiet day. Our guide to software implementation in a working venue covers a plan that makes the first night routine.

The third fear is that staff will resist the new system, use it badly or find ways around it. This is a real risk, and it lasts longer than the switch itself: a system the team dislikes can undermine its own benefits for months.

The actual risk falls sharply when the team is involved early, trained properly and given a system that genuinely makes their work easier. Staff resist systems that slow them down; they adopt systems that help them.

The fourth fear is a contract that cannot be left: long terms, automatic renewals, early termination fees or hardware leases that outlast the software. This is one of the most justified fears, because some contracts really are written to make leaving expensive.

The actual risk is avoidable by reading the contract before signing: the length, the notice period, the renewal terms, the termination fees and who owns the hardware. A contract you understand is one you can plan around.

What actually goes wrong in most switches is more mundane than the fears. A dish set up with the wrong price or the wrong kitchen station. An allergen missing from a dish. A floor plan that does not quite match the room. A future booking that did not move. A payment method not set up. A report that looks different and confuses the accountant.

Each is small, each is fixable in minutes, and most can be caught before the switch by checking the setup carefully. The big disasters owners fear are rare; the small irritations are common and manageable.

Most switches have a few small problems in the first days and none that guests notice. Serious failures, such as a till that will not take payments on a busy night, are rare, and usually come from skipping the testing or switching on the wrong day.

The risk of a bad switch is largely in the owner's hands. A venue that plans, tests and chooses a quiet day takes most of the risk out before the first service.

Set the risk of switching against the cost of staying. A system that is slow, unreliable, expensive or missing features costs something every day: time spent on workarounds, reports combined by hand, guests the venue cannot recognise, fees that grow with trade.

Add up that cost over a year. For many venues, it is far larger than the cost and risk of a well-planned switch, and it keeps growing for as long as the old system stays.

Vendor lock-in describes a situation where leaving a supplier is so costly or difficult that a customer stays even when they would rather not. In restaurant technology, it comes from data that cannot be exported, contracts that cannot be left and hardware that works only with one system.

The best protection is to think about leaving before you join. A system you could leave easily, with your data, is a system you stay with because it is good, not because you are trapped.

The best evidence about a switch comes from venues that have made it. Ask the new supplier for a few customers you can call, preferably venues like yours, and ask them what went wrong, how long it took to settle and what they would do differently.

Ask about support too: how quickly problems were answered, and whether the supplier's promises matched the experience. A supplier confident in its switches will happily put you in touch with customers who made them.

Hardware can tie a venue to a system as firmly as a contract. Tills, terminals and kitchen screens bought or leased for one system may not work with another, and a lease may run for years after the software is gone.

Check what hardware the new system needs, whether your existing devices can be used and what happens to any lease on the old equipment. Systems that run on ordinary tablets and computers make the next switch, whenever it comes, much simpler.

Before switching, insist on four things: your data, a fair contract, a tested setup and support during the switch. Each answers one of the fears, and together they turn the switch from a leap into a plan.

None of them is unreasonable to ask for. A supplier that cannot offer them is telling you something about what staying with them will be like.

Insist on knowing what data you can take in and out. Can the new system import your guest list, and in what format? Can it export your guests, bookings and sales if you ever leave? Ask for specifics, and where possible test them.

Data that can come in but not go out is a form of lock-in. If a system cannot export something today, know that before you rely on it, and keep your own archive of anything you bring in.

Insist on a contract you understand and can live with. Know the length, the notice period, what happens at renewal, any fees for leaving early and who owns the hardware. Prefer short terms and clear notice periods to long commitments with discounts.

Ask what happens to your data when you leave: how long it is kept, whether you can download it and in what form. These questions are easy to ask before signing and hard to fix after.

Insist on testing the new system before you depend on it. Set up the menu, the floor plan, the team and the devices in advance, check them carefully and run a few real services alongside the old system.

A supplier who wants you to switch without testing is asking you to take a risk you do not need to take. A tested setup turns the first night from a gamble into a routine.

Insist on knowing what support is available during the switch and the first weeks: how to reach it during service, how quickly it responds and what it covers. A problem at eight on a Friday needs an answer at eight on a Friday, not on Monday morning.

Ask other venues using the system how support worked for them. Their experience is a better guide than any promise.

Data migration, moving information from the old system to the new, is where most of the real risk sits. Guest lists, future bookings, the menu and historic sales each move differently, and some may not move at all.

Plan each one: what moves, how, who checks it and what stays behind in an archive. Historic sales rarely need to move; keep the old system's reports instead, and compare against them for the first year.

Future bookings are the data most likely to cause visible problems. A guest who booked through the old system expects their table, and a booking that did not move is a guest turned away.

Move every future booking, check each one against the old diary and keep the old system available until the last of them has passed. Tell the hosts clearly which system holds which dates during the changeover.

The till is the most sensitive system to switch, because every sale depends on it. A POS migration needs the menu set up perfectly, every payment method tested, every member of staff able to sign in and a quiet day for the switch.

Our guide to POS migration without losing a Saturday covers the till's move in detail.

Marketing consent does not always move cleanly with the guest list. Consent recorded in the old system may not be accepted in the new one, or may not be provable, and guests who never agreed to marketing may be mixed in with those who did.

Treat consent carefully. Import guests without marketing consent unless it can be shown, and ask them again through the new system. A smaller list of guests who really agreed is worth more than a large one built on assumptions.

Choose the time of year as carefully as the day. Switching in the weeks before the festive season, or at the start of the summer peak, adds risk exactly when the venue can least afford it. A quiet month gives the team time to learn before the busy weeks arrive.

Plan backwards from the quiet period: setup and testing in the weeks before, the switch at the start of the quiet weeks and a settled system by the time trade picks up.

Guests see some switches and not others. A new till is invisible to them; a new booking page, new confirmation emails or a new way of ordering at the table is not. Make the parts guests see as smooth as possible, and tell regulars if anything they use will change.

Keep the old booking links working, or redirect them, until every place they appear has been updated. A guest who finds a broken booking link rarely tries a second time.

Bring the team into the decision early. Show them the new system, ask what they need from it and let a few of them help test it. Staff who helped choose and test a system are far more willing to use it.

Train them before the switch, in short sessions on the real system, and have champions on each team who can help colleagues during the first services.

In a group, switching systems one venue at a time spreads the risk. The first venue's switch teaches lessons for the next, and the team from the first can help train the second.

Start with the venue whose current system causes the most trouble, or whose contract ends first. By the third venue, the plan is well tested and the switch is routine.

The switch has costs of its own: the time to set up the new system, the hours of training, a few weeks of paying for both systems while they run side by side and perhaps new hardware. Count them honestly, so the decision is made on the full picture.

Set them against a year of the old system's costs. For most venues, the switch pays for itself within months; for a few, the numbers say wait. Either way, the decision is better made on numbers than on fear.

A switch can be planned with a short checklist:

Sometimes the right decision is not to switch yet. If the current system works well enough, the contract has a large early termination fee or the venue is about to go through another big change, waiting may be wiser.

Decide deliberately, though, not out of fear. Write down why you are staying and when you will look again, so the decision is reviewed rather than forgotten.

An invented brasserie has kept a slow, expensive till for four years because the owner fears losing the guest list and a bad Saturday. Before switching, the owner checks the four things: the old system can export guests to a spreadsheet and the new one can import them, the new contract is monthly with a clear notice period, the setup will be tested for a week alongside the old till and support is available during service.

The switch happens on a Tuesday after a week of parallel running. Two small menu mistakes are fixed on the first day. The guest list is imported, consent is asked for again and the old system's reports are archived. A month later, the owner wonders why they waited four years.

Moving to servearound starts with setting it up while you trade: the menu is built in the menu editor with each dish's options, allergens and station, the floor plan is drawn in the designer and the team is invited with their roles. 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, so consent is asked for again. Past sales from the old system do not come across, so keep its reports.

On the way out, guests cannot be exported from servearound today, so ask about it before you plan around it, and keep your own archive of anything you bring in; bills for any range of dates download as a spreadsheet. Pricing is per venue, per month, with no fees per cover, order, screen or user: see pricing, or get in touch to talk through a switch.

Small setup mistakes: prices, stations, allergens, the floor plan or a missing booking. Most are caught by testing.

Not if the old system can export it and the new one can import it. Check both before you start.

The length, notice period, renewal terms, early termination fees, hardware ownership and what happens to your data.

Test in advance, train the team and switch on a quiet day.

Not always. Import without consent unless it can be shown, and ask again.

No. One at a time, learning from each.

When leaving a supplier is so costly or difficult that you stay even when you would rather not.

When the current system works well enough, the exit cost is high or another big change is under way.

Switching systems carries real risks, but they are specific and manageable: setup mistakes caught by testing, future bookings protected by careful checking, staff resistance reduced by involving the team, and contract traps avoided by reading the terms. The disasters owners fear are rare; what usually goes wrong is small and quickly fixed.

Insist on four things before you start: know what data can come in and go out, sign a contract you understand, test the setup alongside real services and confirm support during the switch. Plan the data migration and the POS migration carefully, treat owning your guest data as part of the decision and follow a proper software implementation plan, and the switch becomes a project rather than a leap.