In twenty years of running an MSP I’ve watched a lot of restaurant groups try to grow. The ones that make it from a handful of sites to a proper estate almost all hit the same wall, and they hit it in roughly the same place: somewhere between site ten and site fifteen. Up to that point, the founder still knows every general manager by name, the head of operations can hold the whole business in their head, and the IT - whatever it is - works well enough to be ignored. Then the wheels start to wobble.
The mistake people make is assuming that going from 5 sites to 50 is a linear problem. It isn’t. It’s a step change. The operating model that got you to 5 will not get you to 50, and that is true of your people, your processes and your technology. Pretending otherwise costs growing groups an enormous amount of money, and quite often costs them a year or two of momentum at exactly the moment they should be pressing the accelerator.
This post is about the technology side of that step change, written for founders and operations directors who can feel the wall coming and want to know what a scalable stack actually looks like.
The symptoms of a stack that’s run out of road
You usually don’t notice the wall as a single event. You notice it as a slow accumulation of friction that, taken individually, looks like normal growing pains and, taken together, looks like a business that is starting to grind.
The signs are pretty consistent. Ticket volume is rising faster than headcount, and your operations team is spending an embarrassing amount of its week dealing with EPOS resets and printer issues. Site configurations have drifted: every restaurant has the same till software, in theory, but in practice each one was set up by a different engineer on a different day, with different tax codes, different modifier groups, and different printer mappings. Menu changes that were supposed to roll out group-wide on Monday morning are still not live in two sites by Wednesday. Payment reconciliation, which used to take an afternoon, now takes the finance team three days because every site has a slightly different acquirer setup.
Connectivity is a patchwork. There’s a different broadband provider at almost every site, because each one was procured by whoever opened the location, and nobody has a single view of who is up, who is down, or whose contract is about to auto-renew at twice the price. Half the managers have signed up to free WiFi services to keep guests happy. Two sites are running their own Dropbox accounts because the head office system was too slow. Shadow IT is everywhere, and when something breaks, nobody is entirely sure who owns it.
None of this is unusual. It is, in fact, completely normal - and it is also a clear signal that the stack needs to be rebuilt, not patched.
Five pillars of a scalable hospitality IT stack
When I look at the groups that have made the jump cleanly, they all end up converging on roughly the same architecture. There are five pillars.
1. Standardised site builds
The single biggest lever in multi-site IT is standardisation. Every new site should open with the same hardware, the same network kit, the same WiFi access points, the same EPOS template, the same printer model, the same cable management, the same labelling. Boring, identical, repeatable.
The reason is not aesthetic. It’s that a standard site build collapses the support model. Your engineers (or your MSP’s) don’t have to learn ten variations of the same problem. New starters at site level can be trained once and deployed anywhere. Spare parts can be held centrally. When you open site 23, it should look indistinguishable from site 6, because that is what makes site 23 cost half what site 6 did to get running.
Get the build documented. Get it on a checklist. Refuse to deviate from it without a written reason.
2. Centralised identity and access
At 5 sites you can probably get away with a spreadsheet of usernames and a shared Office 365 tenant that someone set up in a hurry. At 15 sites that becomes dangerous. At 30, it’s a serious risk.
The answer is centralised identity, built on Microsoft Entra ID or an equivalent. Every employee - head office, kitchen, floor, manager - has a single identity, with role-based access to the systems they need. MFA is on by default. Joiners, movers and leavers go through a single workflow, so when a manager leaves on a Friday, their access to the rota system, the EPOS back office, the supplier portals and the shared drive all shut off at the same moment, not three months later when finance notices an unused licence.
This is the single change that has the biggest effect on your security posture and your audit story, and it makes everything downstream - onboarding, offboarding, compliance - dramatically cheaper.
3. Consolidated connectivity
A growing group cannot run on a different broadband contract at every site. It is operationally indefensible and commercially wasteful. Somewhere around 10 sites you need to consolidate connectivity through a single broker or, better, an SD-WAN with resilient lines and a single pane of glass for monitoring - the kind of thing our franchise connectivity work is built around.
What you want is the ability to look at one screen and see the status of every site in the estate, with alerts before a manager has to ring head office. You want a 4G or 5G failover at every location so that a fibre cut on a Friday night does not take down service - we cover the options on our business internet page. And you want one number to call when something breaks, with one provider who is accountable for the whole estate.
We’ve written more about how this works on our managed network page, but the principle is simple: connectivity is not a per-site purchase any more, it’s a group-level capability.
4. Cloud-first reporting and BI
By the time you are running 15 sites, you cannot afford to be making decisions on yesterday’s data - and you certainly cannot afford to be making them on data that has to be exported manually from each site’s EPOS, emailed in, and stitched together in a spreadsheet on a Tuesday morning.
The scalable pattern is to pipe EPOS, labour, stock and reservations data into a cloud data warehouse, and put Power BI (or an equivalent) on top of it. Every site reports up automatically, in close to real time. Operations directors get group-level dashboards, area managers get their patch, individual GMs get their site. The same numbers, refreshed overnight, that nobody has to argue about because they all came from the same place.
This is where managed cloud earns its keep. The underlying plumbing - secure data ingestion, identity, governance, backup - is not something an operations team should be trying to build in-house. But the result, which is timely and trustworthy group-level reporting, is genuinely transformational for a multi-site business.
5. Security and compliance as a layer
The last pillar is the one that nobody wants to think about and everyone regrets ignoring. As you grow, you become a more attractive target and a more accountable one. Card data flows through more terminals. Guest data sits in more booking systems. Suppliers ask harder questions. Insurers ask harder questions. PCI DSS stops being a tick-box and starts being a real piece of work.
You need network segmentation between corporate, EPOS, payment and guest WiFi at every site. You need endpoint protection and monitoring on every device that matters. You need a route to Cyber Essentials, and if you’re handling enough volume, Cyber Essentials Plus. And you need someone watching the alerts at three in the morning, because that is when things happen.
If you want a fuller picture of what good looks like here, our cyber security work goes into more detail. The headline is that security is not a project you do once. It’s a layer that sits across the whole stack, all the time.
How to actually get from where you are to there
Knowing what the destination looks like is the easy part. Getting there without breaking the business is harder. In practice, I’ve seen three migration patterns work.
Rip and replace is rare and expensive, but occasionally the right answer for groups that have been bought, are mid-rebrand, or are about to undergo a major refit anyway. You take a weekend, you swap everything, you accept the pain. It’s only viable at smaller estates and only when there’s a forcing event.
New sites first, then retrofit is the pattern I see most often, and it’s usually the most pragmatic. You define the new standard, you open every new site on it from day one, and you retrofit the existing estate at a measured pace - typically alongside refurbishments or lease events. Within eighteen to twenty-four months the whole estate is on the new model without ever having to shut anything down for the sake of it.
Gradual site-by-site refresh works when you have no new openings in the pipeline and need to modernise the existing estate in place. You pick a pilot site, you nail the build, you write the runbook, and then you work through the estate at one or two sites a month. It’s slower, but it’s controllable, and it lets you learn as you go.
There is no single right answer. The right answer depends on how many sites you have, how fast you’re opening, and how much pain the current stack is causing you right now.
When to bring in a hospitality specialist MSP
There comes a point at which the question stops being “do we need an MSP” and becomes “what should the relationship with our MSP look like”. Most groups I see are well past that point by the time they ring us.
What you want from a hospitality specialist is not a generic break-fix service. You want a franchise IT support partner who has done multi-site rollouts before, who understands EPOS and PMS integrations, who knows what a Friday night looks like in a 200-cover restaurant, and who has a real opinion about the difference between a good network design and a bad one. You want fixed pricing per site, clear SLAs that distinguish between a printer not working and a card terminal being down, and a single point of accountability across hardware, software, network and security.
You also want them to push back on you. A good MSP will tell you when you’re about to do something silly, even if it costs them the install fee.
What the IT function looks like at 5, 15, 30 and 50 sites
The shape of the internal IT function changes as you grow. At 5 sites, you almost certainly don’t need an internal IT lead. Operations and finance share the responsibility, and an MSP handles everything technical. At 15 sites, you probably want an IT and systems coordinator - someone internal who owns vendor relationships, runs the change calendar, and is the bridge between operations and the MSP. At 30 sites, that role becomes a head of IT or head of technology, with a small internal team handling project work and a deeper MSP relationship handling run. At 50 sites, you have a proper technology function, with applications, infrastructure and data sitting alongside each other, and the MSP relationship is much more about specialist capability and out-of-hours coverage than day-to-day support.
The mistake is hiring the head of IT too early - before there’s enough work to justify it - or too late, when the absence of an internal owner is already costing you in poor decisions and badly negotiated contracts.
The CloudMatters point of view
We’ve spent the last two decades helping London hospitality groups grow. We’ve done the rip-and-replace weekends, the eighteen-month retrofits, the new-site rollouts that opened on time because the build was boring and predictable. We’re a hospitality specialist by choice, because the operational realities of running a restaurant on a Friday night are not the same as running a law firm on a Tuesday morning, and the IT decisions that follow from that are different too.
If you’re somewhere between 5 and 50 sites, and you can feel the wall, we’d be happy to talk it through - even if all you want is a second opinion on the architecture you’re already planning. Our hospitality IT support page is the right place to start.
The good news is that the step change is well understood. It is not a mystery, and it is not a matter of luck. The groups that make it through do it deliberately, and the ones that get stuck almost always get stuck because they tried to scale a 5-site stack to 50 sites by adding more of the same. Don’t do that. Build the stack you’ll need at 50 while you’re still at 12, and the next forty sites will be the easiest part of the journey.