Switching EPOS
Switching till providers terrifies restaurant owners, and honestly, it should — done badly, it costs you a weekend. Done properly, your customers never notice. Here's the full playbook: contracts, data, card machines, training, timing, and the rollback plan nobody tells you to make.
I watched a restaurant go live on a new till system at 6pm on a Friday. Not watched from a safe distance — I was standing ten feet from the counter while it happened. The owner had been promised a "smooth transition" (his words, quoting the sales rep, doing the air quotes himself by that point). By 7:30 the kitchen printer had stopped talking to the till, nobody could work out how to split a bill, and the card reader was declining every third transaction for no reason anyone could explain. They lost the evening. Not some of it. All of it — walkouts, comps, a one-star review posted from table nine while the staff were still apologizing.
Monday morning the owner rang me. He wasn't angry at the new system, which is the interesting bit. He was angry at himself. "We did everything on their timeline," he said. "Nobody told us we could do it on ours."
That's what this article is. Your timeline. The whole thing — getting out of your old contract without getting stung, moving your menu without rebuilding it from memory at midnight, the card machine trap everyone walks into, training staff who'd rather be anywhere else, and picking a go-live day that doesn't involve the words "Friday" or "evening."
Why you're switching (be honest about it)
People switch for four reasons. Every migration I've ever seen was one of these wearing a disguise.
One: the price went up.Two: support died.Three: you outgrew it.Four: the hardware's dying and the software's coming with it. The old Windows till is on its last legs (you read the grease section in our last article — you know), and the provider's "upgrade path" is a five-figure quote. Sometimes switching is just the cheapest way to get working hardware.
Know which one you are. It changes what you prioritize in the new provider. Price-switchers should obsess over the new contract's renewal terms (or you'll be writing this same article in two years). Support-switchers should test the support line before signing — ring it at 7pm on a Friday and see who answers. Out-growers need multi-site features that actually work, not a tick box on a brochure.
The fear is legitimate. Price it.
Let's put a number on what "losing a weekend" means, because vague fear makes bad decisions and specific fear makes plans.
A decent independent doing £8,000 across Friday and Saturday: lose both days and you're down £8,000 in revenue, plus the food you've prepped and can't sell, plus staff wages for a shift spent apologizing, plus the reviews. Call it £10,000 all-in, easy. For a busy site doing £20k weekends, double it.
That's why people stay with terrible providers for years. It's not laziness — it's arithmetic. The devil you know is taking your money slowly; the devil you don't might take a weekend all at once. Totally rational fear.
But here's the thing the fear hides: a proper migration doesn't risk the weekend at all. The whole point of doing it right is that the risky bit happens on a Tuesday afternoon when you've got twelve covers in, not a Friday when you've got a hundred. The restaurants that lose weekends are the ones who let the new provider's onboarding team schedule the go-live. Whose weekend is it? Yours. Whose timeline? Should be yours too.
Your old provider will not help you leave
Read that heading again. Internalise it. Then read your contract.
Most UK EPOS contracts are 12 months minimum, many auto-renew for another 12 if you don't give notice — usually 30 days, sometimes 90, always buried in clause somewhere past where anyone reads. Miss the window and congratulations, you've bought another year. Set a calendar reminder the day you sign anything. I'm serious. The single most expensive sentence in hospitality tech is "I thought it was monthly."
Notice periods are the first trap. Exit fees are the second. Some providers charge them openly — a few hundred pounds, annoying but honest. Others hide them as "hardware lease settlements" (that "free" till wasn't free, it was a lease, and you're paying the balance) or "data extraction fees." Yes, really. Some providers charge you to get your own menu data out. Ask about this before you sign the new contract, not after — you want the ugly numbers while you still have the upper hand, which is to say, before the old provider knows you're leaving.
And then there's your data. Your menu, your prices, your staff records, your sales history, your customer database — it's yours, legally, under GDPR. Practically? It's in their system, in their format, behind their login. Most providers will give you a CSV export if you ask firmly. Some make you ask three times. One provider I know of (not naming names, but their sales reps wear very nice suits) initially told a customer their sales history "couldn't be exported for technical reasons," then miraculously found the export button when the customer mentioned the ICO. Funny how that works.
Get everything before you cancel. Menu with prices and VAT settings. Staff list with roles and PINs (you'll reset the PINs, but the list saves retyping). Full sales history — at least two years, ideally everything. Customer database if you have one, with consent records. Supplier-linked product codes if your stock system talks to the till. Export it all, save it in two places, and only then send the cancellation notice. The order matters: data first, goodbye second. Once you've cancelled, your bargaining position is a memory.
One more: check who owns your card processing agreement. Sometimes the EPOS contract and the merchant services agreement are separate — you can leave the till provider but you're still tied to their payments partner for another year. Sometimes they're bundled and leaving one means renegotiating the other mid-migration. Know which you've got before you move a single menu item.
What actually transfers (less than you think)
Here's the conversation every migrating restaurant has, usually about a week before go-live, usually with rising panic: "so the new system just... imports everything, right?"
Right in theory. In practice: sort of. Maybe. Depends.
Menu items and prices: usually importable via CSV, if your old provider gives you a clean export (see above — get it before you cancel) and your new provider's onboarding team isn't having an off week. Budget an afternoon to check every price, because CSV imports love to do things like drop the £ sign, mangle special characters (your "crème brûlée" becomes "cr?me br?l?e"), and silently skip items with apostrophes. Posh Nosh's becomes Posh Nosh. Your customers will notice before you do.
Modifiers and courses: this is where migrations go to die. Your "burger ? add cheese (+£1.50) ? no onion ? gluten-free bun" modifier tree almost certainly does not map neatly onto the new system's modifier logic. Every EPOS vendor builds modifiers differently — some nest, some don't, some charge per modifier group, some per item. Expect to rebuild these by hand. It's tedious, it's the bit everyone underestimates, and it's where errors hide. The wrong modifier price on a busy Friday is death by a thousand 50ps.
VAT settings: eat-in versus takeaway, alcohol versus food, the children's menu edge cases. The UK's VAT rules for hospitality are fiddly enough when you're setting them up fresh; migrating them means verifying every single item's tax treatment in the new system. Get one wrong across hundreds of transactions and you've got a VAT return problem. Boring. Important. Do it with coffee, not at midnight.
Allergens: Natasha's Law didn't go away while you were switching providers. Every prepacked item needs its allergen labeling intact through the migration. If your old system held the allergen matrix and the new one needs it re-entered, that's a job, not a checkbox. Don't discover this during an EHO visit.
Staff and PINs: easy. An hour, tops. Reset all PINs during migration — it's good hygiene anyway, and half your ex-staff probably still remember theirs.
Sales history: import it if you can, but be honest about why. You want year-on-year comparisons and your accountant wants continuity. What you don't need is seven years of individual transactions clogging the new system. Two years of daily totals covers 95% of real use. Anyone telling you to migrate every receipt since 2019 is selling storage.
Discounts, loyalty, gift cards: the minefield. Outstanding gift card balances have to work on day one of the new system or you're having an argument with a customer holding £50 of your gift card and zero patience. Migrate the balances, test one before go-live, and have a paper backup list of outstanding cards for the first week. Loyalty points: pick a cutover date, honour old points in the new system or cash them out, communicate it clearly. This is customer-trust territory — get it wrong and the till isn't the problem, the Facebook post is.
The card machine trap (everyone walks into this one)
You've migrated the menu. Staff are trained. Hardware's in. Then someone asks: "what about the card machines?" Silence. This is the bit that derails more migrations than anything else, because people assume card processing just... follows them. It doesn't. It's a separate agreement with separate plumbing.
Three scenarios. One: your new EPOS provider has its own integrated payments (or a preferred partner like Dojo, Zettle, or Square) and you're moving across. That means a new merchant agreement, new boarding, new settlement account details. Boarding takes days, not hours — the underwriting checks are real, and they don't care about your go-live date. Start this the day you sign, not the week you migrate. I've seen a restaurant ready to go live on everything except card payments, taking cash only for three days while the merchant account cleared. In 2026. Cash only. The staff still talk about it.
Two: you're keeping your existing card provider and just pointing the new till at it. Cleaner — if the new till integrates with your reader. Verify this with both vendors in writing before you commit. "We integrate with Dojo" and "we integrate with your specific Dojo Go setup on our software version" are different statements. Get the second one.
Three: you're switching card providers at the same time as the till. Don't. Just... don't. One migration at a time. Switching the till and the payments processor simultaneously means when a transaction fails, nobody knows which side broke it, and both support lines point at each other while your queue grows. Migrate the till, settle for a month, then move payments if you still want to. Your future self will thank you. Your current self might not believe it, but trust me.
Whatever scenario you're in: run test transactions before go-live. Real ones — a £1 sale, a £1 refund, a void, a split bill across two cards. Refund the £1s immediately and check they land. Check settlement timing (next-day? two-day? — it affects your cash flow and your accountant's mood). And confirm what happens to offline authorizations if your internet drops mid-service. Liability for failed offline payments usually sits with you. Read that bit twice.
Hardware: keep it, replace it, or bin it
Good news first: the boring peripherals usually survive. A Star TSP143III or Epson TM-m30 receipt printer doesn't care which software talks to it — it's a printer, it prints what it's told. Cash drawers trigger via the printer on virtually every system, so if the printer works, the drawer works. Barcode scanners are basically keyboards that type really fast; they work with everything.
Tablets are the question mark. iPads: if they're under five years old and the new provider does iOS (most do), keep them. Wipe, reinstall, done. Android tablets: depends entirely on the model and the new provider's supported list — that £129 special from the last article? This might be its natural end. Check before you assume.
Windows all-in-ones: if the new system's browser-based, they might survive as dumb terminals. If it needs a native app, they might not. And if the machine was already wheezing, a migration is a good excuse to stop throwing good money after bad. Be honest about whether you're keeping it because it works or because you paid a lot for it in 2021.
Stands, enclosures, mounts: keep. They're furniture. Nobody's till software cares about your stand.
The rule: list every piece of hardware, check each one against the new provider's compatibility list, and get the answer in writing from someone whose name you know. "Should work" from a sales rep is worth nothing. "Yes, the TSP143IIIU is on our supported list, confirmed by our on-boarding team" is worth everything. The gap between those two sentences has ruined weekends.
Tuesday. Always Tuesday.
The single most important decision in your migration isn't the provider. It's the day.
Go live on a Tuesday. Or a Wednesday. The quietest day you have — the day you'd least mind closing for an hour if it came to it. Not Friday. Not Saturday. Not the week before Christmas, not Valentine's week, not Mother's Day, not during the World Cup if you're a pub. I shouldn't have to say this, but the Friday-6pm story at the top of this article happened because the provider's on-boarding team had a free slot Friday afternoon and nobody pushed back. Their slot. Your weekend. See the problem?
Tuesday gives you something precious: runway. Something breaks Tuesday lunchtime, you've got Tuesday afternoon, Wednesday, Thursday to fix it before the weekend. Something breaks Friday night, you've got panic. Runway is everything.
And go live at lunch, not dinner. Quieter, slower, staff are fresher, and if you need to roll back (more on that in a minute), you've got the whole afternoon. A lunch go-live that wobbles is a story. A dinner go-live that wobbles is a disaster with witnesses.
Training staff who'd rather be anywhere else
Your staff don't care about your new EPOS system. This isn't cynicism, it's fact — they care about getting through the shift without looking stupid in front of customers. Train to that, not to the feature list.
Thirty minutes per person, max. Not a two-hour seminar — nobody retains hour two of a till seminar, they've mentally left after twenty minutes. Thirty minutes, hands on the actual till, doing the actual things: ringing in the five bestsellers, applying the staff discount, splitting a bill three ways, voiding an item, firing a refund. The greatest-hits of a shift. Everything else they learn on the job, same as they did with the old system.
Tape a cheat sheet to the wall next to the till. One page. The ten things people forget under pressure: voids, discounts, split bills, refunds, no-sale drawer open, card machine reprint. Laminate it — it'll get splashed. This single sheet will prevent more mid-service meltdowns than any amount of training, because panic wipes memory and paper doesn't panic.
And identify your champion. Every venue has one — the person who's good with tech, who the others ask when something's weird. Train them first, train them deeper, give them the support line number. On go-live day, they're your first line of defense. Pay them for the extra session. A tenner and a thank-you now saves you forty phone calls later.
One thing people skip: train the kitchen too. Not on the till — on what the tickets look like. New system, new ticket layout, maybe new routing. If the kitchen's never seen the new ticket format before a live service, your expo station becomes a translation service. Print sample tickets, stick them on the pass, walk the kitchen team through it for ten minutes. Ten minutes. That's all it takes to stop the "what does this mean" shouting on day one.
The quiet go-live (and the rollback plan nobody makes)
Two ways to go live. The hard cut-over: old system off Tuesday morning, new system on, no safety net. Clean, simple, terrifying. Or the parallel run: both systems live side by side for a few days, new system taking real orders, old system warm as backup.
I'm a parallel-run person, with a caveat. Running both means double entry for a few days — everything rung on the new till, key figures cross-checked on the old. It's extra work, and staff will moan. But for three days you've got a fallback that isn't panic. The caveat: cap it at three days. Longer than that and staff start using the old system "because it's easier," and you've paid for a migration you've quietly abandoned. Three days, then the old till gets unplugged and put in the office. Ceremony helps — make it an event, not a drift.
Now the rollback plan. Nobody makes one. Everyone needs one.
Write down, before go-live: at what point do we abort? Define it cold, while you're calm. Mine would be: if we can't take card payments for more than 30 minutes, or if the kitchen stops receiving tickets, we roll back. Your thresholds might differ. The point is deciding them now, not at 8pm with a dining room full of people and adrenaline doing your thinking.
Rolling back means: the old till, still configured, still logged in, sitting in the office (not wiped, not returned, not in a box). The old card reader, charged. The paper backup pad and a calculator in the drawer — yes, really, paper. If everything electronic fails simultaneously, paper and a card machine with manual entry keeps you trading. It's 2026 and I'm telling you to keep paper by the till. The restaurants that sailed through their worst tech nights all had paper. The ones that didn't, didn't.
Tell the team the rollback plan exists. Not to scare them — the opposite. People handle wobbles far better when they know there's a plan B. "If this goes sideways, we do X" turns panic into procedure.
The week before, the day before, the day
A week out: menu imported and every price checked. Modifiers rebuilt and tested. VAT settings verified item by item (coffee, not midnight — remember). Allergens re-entered. Staff PINs reset. Gift card balances migrated and one test redemption done. Card processing boarded, test sale and refund completed, settlement timing confirmed. Hardware compatibility confirmed in writing. Cheat sheet printed and laminated. Kitchen has seen the new ticket format.
The day before: full test service. Not clicking around — a real rehearsal. Two people play customers, one plays the till, run twenty covers through it: orders, modifiers, split bills, discounts, voids, refunds, a gift card, a loyalty redemption. Time it. Whatever breaks, breaks now, when the only witness is you. Charge every device overnight — tills, card readers, the backup phone with the 4G hotspot. Check the paper backup pad is actually in the drawer.
Go-live day (Tuesday, lunch): champion on the till for the first hour. You on the floor, not in the office — visible, calm, available. Old till warm in the office, not wiped. Support line number saved in your phone and the champion's. First real transaction: watch it like a hawk — order in, ticket in kitchen, payment taken, receipt correct. Then breathe. Check in with the kitchen after the first ten tickets: is the format readable, is routing right, any surprises? Small fixes now, big relief later.
That evening: run the day's reports. Do the totals match what you'd expect? Any missing transactions, any double-charges? Reconcile against the card processor's dashboard — they should agree to the penny. If they don't, you want to know tonight, not at month-end. Then — and only then — start thinking about the weekend with something resembling confidence.
What I'd actually do
No summary — you just read the thing. Here's the honest closer instead.
Most migrations fail for boring reasons: the contract wasn't read, the data wasn't exported before cancelling, the card machine was an afterthought, the go-live was scheduled for someone else's convenience. None of that is a technology problem. It's a planning problem, and planning is free.
If you're switching because the price went up: read the new contract's renewal clause before you sign. The cheapest quote with an auto-renewing 36-month term isn't cheap, it's a trap with a bow on it. If you're switching because support died: ring the new provider's support line at 7pm on a Friday before you commit. Whoever answers — or doesn't — is your answer.
And give yourself six weeks. Not two. Six. Two weeks is how long the sales rep says it takes; six weeks is how long it takes when you do the data export properly, rebuild the modifiers without rushing, rehearse a full service, and go live on a Tuesday with runway. The extra month costs you nothing. The rushed fortnight can cost you a weekend.
We migrate restaurants onto CubePOS regularly, and the ones that go well all look the same: data exported before cancellation, Tuesday go-live, cheat sheet on the wall, old till in the office for a week. The ones that go badly all look the same too — and it's never the software. It's Friday, it's rushed, it's the card machine nobody thought about. Don't be the Friday story. Be the Tuesday story nobody ever hears about, because nothing went wrong.
Thinking of switching? Book a free CubePOS demo and we'll walk you through the migration properly — data export, hardware check, card processing, and a go-live plan built around your quietest day, not ours.