Multi-site network design is the decision most UK businesses make by accident. The second office gets a site-to-site VPN back to head office because that is what the firewall at head office already does. The third office gets the same. By the sixth site somebody notices that a file transfer between Leeds and Bristol is travelling through London, that adding a site now means touching five existing firewalls, and that nobody can draw the network on a whiteboard without arguing about it.
This guide takes the position that topology is the decision that matters, and that it should be made before anyone chooses a connection type. It works through hub-and-spoke against full and partial mesh and the arithmetic that makes the difference concrete, the cloud-native transit model that has displaced the head-office hub for most new designs, the genuine trade-offs between site-to-site VPN and SD-WAN for branch office connectivity, and the addressing, routing and resilience decisions that determine whether adding a seventh site is a morning of work or a project. It covers indicative 2026 UK costs per site, realistic latency and throughput figures, and the specific design choices that are cheap to make at the start and expensive to reverse at site number eight.
What multi-site network design actually decides
A multi-site network has to answer four questions, and they are usually answered in the wrong order. The first is topology: which sites talk to which, and through what. The second is transport: what physical or logical circuit carries the traffic. The third is policy: where inspection, filtering and egress happen. The fourth is addressing: how IP space, routing and name resolution are organised across the whole estate.
Most organisations start at question two, because transport is the part with a price attached and a supplier attached. A circuit can be ordered, a firewall can be bought, and something visibly happens. Topology, by contrast, is a diagram, and diagrams do not feel like progress. The result is a network whose shape was never chosen — it emerged from the order in which sites were opened and from whatever the incumbent firewall could do at the time.
The reason topology deserves to come first is that it constrains everything downstream and is the hardest thing to change later. Transport can be swapped: a branch can move from FTTP to a leased line over a weekend, and the rest of the network does not care. Policy can be relocated with configuration. Addressing can be renumbered, painfully. Topology change means re-pointing every tunnel on every device simultaneously, which in practice means a cutover weekend and a rollback plan, for every site at once. Organisations rarely do it twice.
The second reason is that topology determines the operational cost of growth. This is the part that does not show up in the business case, because the business case is written when there are three sites and the pain arrives at eight. A design where adding a site is a single configuration change at one place and a device shipped to the branch is a fundamentally different proposition from one where adding a site is a change at every existing site, even if the two cost the same on the day they are installed.
Before evaluating any product, write down the traffic matrix: for each site, what proportion of its traffic is destined for the internet or a cloud platform, for head office, and for another branch. Most organisations discover that the branch-to-branch figure they were designing around is close to zero, because the applications everyone shares moved to Microsoft 365 or Azure years ago. That single table usually settles the hub-and-spoke versus mesh argument in about ten minutes, and it is the artefact that makes every subsequent supplier conversation shorter.
The tunnel-count problem — why mesh stops scaling
A full mesh connects every site directly to every other site. The appeal is obvious: the shortest path between any two points, no dependency on a central location, no hairpinning. The problem is arithmetic. The number of tunnels in a full mesh is n(n-1)/2, and that curve is steeper than anyone expects when they are looking at a four-site network. The chart below shows tunnel count against site count, scaled to the twelve-site figure.
Three sites to four sites doubles the tunnel count. Six sites to twelve sites multiplies it by more than four. Each of those tunnels is a phase-one and phase-two configuration, a pre-shared key or certificate, a pair of firewall rules, a monitoring target and something that can expire, mismatch or silently drop. At twenty-eight tunnels, a manually managed mesh is a full-time job for somebody, and the failure mode is not a dramatic outage — it is one tunnel that has been down for three weeks and nobody noticed because the traffic quietly took another path.
Hub-and-spoke replaces that curve with a straight line. Every site holds one tunnel to the hub, so n sites means n tunnels, and adding a site is one configuration at the branch plus one at the hub. Twelve sites means twelve tunnels rather than sixty-six. The cost is that branch-to-branch traffic transits the hub, adding the round trip to and from the hub location to the path, and that the hub becomes a component whose failure affects everything.
This is where the traffic matrix earns its place. If branch-to-branch traffic is two per cent of the total, paying a latency penalty on two per cent of flows to remove fifty-four tunnels from the estate is an easy trade. If two sites run a latency-sensitive application directly between them — a manufacturing site and a design office sharing a CAD workspace, say — the answer is not a full mesh, it is hub-and-spoke with one direct tunnel added between that pair. Partial mesh is not a compromise position, it is usually the correct answer, and the discipline is to add direct paths only where a named application justifies one.
Multi-site connectivity in UK businesses — the numbers
The figures below reflect what we typically find when reviewing an existing multi-site estate for a UK organisation running between three and fifteen locations. They describe networks that grew site by site rather than ones designed as a whole, which is the overwhelming majority of what exists.
The first figure is the one that has changed the design conversation over the last decade and still has not fully filtered through to how networks are built. When the applications lived on a server in the head office comms room, backhauling every branch to head office was not a design choice, it was a physical necessity. Now that mail, files, telephony, finance and the line-of-business application are all reached over the internet, backhauling branch traffic to head office so it can leave through the head office firewall means sending it in the wrong direction twice.
The third figure is the quiet killer. Overlapping address space — three sites that each helpfully used 192.168.1.0/24 out of the box — does not cause a problem until those sites need to route to each other, at which point it causes a problem that cannot be configured around. It has to be renumbered, and renumbering a live site means touching DHCP scopes, static reservations, printers, access control systems, door entry, CCTV and whatever else was given a fixed address by somebody who has since left. It is the single most common reason a multi-site consolidation takes three months instead of three weeks.
The fourth figure is the operational one, and it is the argument that carries weight with a board. Two days of engineering per new site, multiplied by an expansion plan, is a real number that can be compared against the cost of designing the network properly once.
Hub-and-spoke, mesh, and the hybrid in between
The phrase hub-and-spoke network architecture covers several things that behave quite differently, and being specific about which one is under discussion avoids a good deal of confusion later.
Traditional head-office hub
Every branch holds a tunnel to a firewall at head office. Branch-to-branch traffic transits head office, and so does internet traffic if the design backhauls it. This was the standard UK SME pattern for twenty years and it still exists widely. Its weaknesses are structural: the head office circuit carries traffic that has no business being there, the head office firewall is sized for the whole estate rather than for head office, and a head office outage takes every branch with it. Head offices also move, and moving a head office that is also the network core is a considerably larger undertaking than moving an office.
Cloud-hosted hub
The hub function moves into a cloud platform — an Azure hub virtual network, a Virtual WAN hub, or a virtual appliance running in the cloud — and head office becomes just another spoke. This is the default for new designs and for good reason. The hub sits adjacent to where most of the traffic is already going, it is not tied to a building on a lease, it scales by changing a SKU rather than by shipping hardware, and it can be made zone-redundant far more cheaply than a second comms room can be built.
Full mesh
Every site to every site. Justified when there is genuine any-to-any traffic with latency sensitivity, which in UK SME and mid-market estates is uncommon. Modern SD-WAN platforms make a full mesh administratively viable by building the tunnels automatically, which removes the configuration objection but not the underlying complexity in troubleshooting and policy.
Partial mesh — hub-and-spoke plus exceptions
A hub for the general case, with direct tunnels between the specific pairs of sites that have a demonstrated need. This is where most well-designed multi-site networks end up. The discipline that keeps it clean is requiring a named application and a measured requirement before any direct path is added, because a partial mesh that accumulates exceptions without that test becomes a full mesh that nobody planned.
One distinction worth holding onto: hub-and-spoke for routing and hub-and-spoke for security policy are separable decisions, and modern designs frequently split them. Traffic can egress locally at the branch for performance while policy is still enforced centrally, either by a cloud security service the branch sends its internet traffic to, or by pushing a consistent policy set down to every branch device from a central controller. Assuming that centralised policy requires centralised routing is the assumption that produces unnecessary backhaul, and it is worth checking explicitly whenever someone argues that traffic must come back to head office for inspection.
Where multi-site designs typically fall down
The grid below groups the recurring weaknesses we find on review. The badges reflect how often the issue appears combined with how disruptive it is to fix once the network is live — a high-risk item is common and expensive to correct later, not necessarily an immediate outage risk.
Two of these compound each other in a way worth spelling out. Firewall rules that have diverged site by site, combined with no central monitoring, produce a network where nobody can confidently say what is permitted where. That is a problem in its own right and it is also a Cyber Essentials problem, because the boundary firewall controls require a documented and reviewed rule set rather than an accumulated one. Organisations pursuing certification across a multi-site estate frequently find that the network audit is the longest part of the exercise, a pattern we cover in our guide to the Cyber Essentials Plus technical audit.
The flat-network item is the other one that deserves emphasis. A multi-site network that routes every site to every other site without segmentation has not built one network, it has built one broadcast-domain-shaped security incident waiting for a compromised device at the least well-managed location. Segmentation at each site — separating corporate devices, guest access, voice and building systems onto distinct VLANs with policy between them — is part of multi-site design rather than a separate project, and it is far cheaper to implement during a rollout than to retrofit. We go into the practical approach in our guide to network segmentation for UK SMEs.
Site-to-site VPN versus SD-WAN for branch connectivity
This is the comparison most multi-site conversations reduce to, and it is worth framing correctly: these are not competing transports. Both carry traffic over the same circuits. The difference is in how the overlay is built, managed and steered. A site-to-site VPN is a tunnel you configure; SD-WAN is a fabric that configures tunnels for you and makes per-application decisions about which path each flow takes.
Site-to-site IPsec VPN
Manually configured tunnels between firewalls
SD-WAN overlay
Controller-built fabric across multiple transports
The crossover point in our experience sits at around five sites, though it moves depending on two things. The first is how often sites are added or changed; an organisation opening two locations a year reaches the operational argument much sooner than one that has been static for a decade. The second is whether anybody in-house genuinely enjoys managing IPsec. A competent network engineer can run a twelve-site manual VPN estate perfectly well, and some do. The risk is concentration: that estate becomes dependent on one person who understands why a particular phase-two lifetime was set the way it was.
The application-awareness line is the one that changes user experience rather than administration. A plain VPN sees packets; it can prioritise by DSCP marking if something marks them, but it cannot distinguish a Teams call from a backup job on the same tunnel. SD-WAN platforms identify applications and apply per-application policy — voice over the lowest-jitter path, bulk replication over the cheaper link, Microsoft 365 broken out locally rather than backhauled. On a branch with one good circuit and one indifferent one, that is the difference between usable voice and a complaint every Tuesday.
Where SD-WAN is oversold is as a replacement for capacity. It routes intelligently around congestion and impairment; it does not create bandwidth. A branch with a saturated circuit will have a better-managed experience of saturation, and users will still notice. Getting the capacity sizing right first is the prerequisite, and we set out the method in our guides to bandwidth planning for a growing UK business and the fuller transport comparison in SD-WAN against MPLS and internet VPN.
Cloud-native hubs and the transit model
If the hub is moving into the cloud, it is worth understanding what the platforms actually provide, because the naming is inconsistent and the cost profiles differ substantially.
The do-it-yourself hub virtual network
A hub virtual network in Azure containing a VPN gateway, optionally a firewall, and peered to spoke virtual networks holding the workloads. Branches build IPsec tunnels to the VPN gateway. This is the classic hub-and-spoke reference design, it is well documented, and it gives complete control. It also means you own the routing: spoke-to-spoke traffic requires user-defined routes pointing at the firewall, and branch-to-branch traffic requires the gateway to be configured to allow transit. The pieces are all standard, but there are enough of them that the design deserves to be drawn before it is built.
Managed virtual hubs
Azure Virtual WAN provides a managed hub in a region that terminates site-to-site VPN, point-to-site VPN and ExpressRoute connections, and handles transit routing between them without user-defined routes. Adding a branch is registering a VPN site against the hub. For an organisation with more than a handful of sites, the reduction in routing complexity is the main attraction; the trade is less granular control and a cost model with a standing hourly charge for the hub plus per-connection and per-gigabyte processing charges.
That cost model is worth modelling before committing, because the standing charges accrue whether the hub is busy or idle. Managed hubs, gateways and firewalls all bill by the hour in the cloud, which makes them exactly the category of always-on resource that drives unexpected cloud spend when a design is stood up for a proof of concept and left running. We cover that pattern and how to catch it in our guide to preventing Azure bill shock.
Vendor virtual appliances in the cloud
Running the same SD-WAN vendor appliance as a virtual machine in the cloud, so the cloud becomes another node in the same fabric as the branches. The advantage is one control plane, one policy language and one dashboard covering branches and cloud alike, which matters more for day-to-day operations than any individual technical capability. The considerations are the virtual appliance licence, the throughput ceiling of the instance size chosen, and building a resilient pair rather than a single instance, since a single virtual appliance carrying the whole estate reproduces the head-office-hub failure mode in a new location.
Private circuits into the cloud
ExpressRoute in Azure, and its equivalents elsewhere, provide a private circuit into the cloud platform rather than traffic traversing the public internet. The arguments for it are predictable latency, a supported throughput commitment and, for some organisations, a compliance position about where traffic travels. The argument against is cost: a private circuit plus the port charge is a materially larger monthly figure than an internet circuit with an IPsec tunnel over it, and for many UK SMEs the internet path to a UK Azure region performs well enough that the difference is not observable in use. It is worth measuring before assuming either way.
What a multi-site rollout actually looks like
The sequence below is for an organisation consolidating an existing ad-hoc estate onto a designed topology, which is the more common and more difficult case. A greenfield rollout follows the same order with the audit and renumbering phases considerably shorter.
Sixteen weeks for a consolidation of eight to twelve sites is realistic where the sites are straightforward and someone is dedicated to the work. The phases that compress well are the migration waves, which can run faster with more hands. The phases that do not compress are the audit and the renumbering, because both are bounded by discovery rather than by effort — you cannot find the undocumented static IP any faster by assigning two people to look for it.
Indicative UK costs per site
The figures below are indicative monthly costs per branch site in the UK during 2026, excluding VAT and excluding installation. They assume a small to medium branch of roughly 10 to 40 staff. Actual pricing varies considerably by postcode, by carrier presence and by contract term, and leased line quotes in particular swing widely depending on distance to the nearest point of presence, so treat these as a basis for budgeting rather than as a quotation.
| Branch connectivity option | Typical bandwidth | Indicative monthly cost per site | Where it fits |
|---|---|---|---|
| FTTP business broadband with IPsec to hub | 150–900 Mbps down, 30–110 Mbps up | £45–90 | Small branches; acceptable where downtime is tolerable |
| Dual FTTP from diverse carriers with SD-WAN | 2 x 500 Mbps typical | £150–260 including licence | The value sweet spot for most UK branches in 2026 |
| Leased line, uncontended symmetric | 100 Mbps–1 Gbps symmetric | £280–650 | Sites with an SLA requirement or heavy upstream use |
| Leased line primary with FTTP or 5G failover | Symmetric primary, broadband secondary | £340–760 | Revenue-critical sites where an outage stops trading |
| 4G or 5G only, with SD-WAN device | 30–300 Mbps, variable | £60–140 | Temporary sites, pop-ups, and failover for the above |
The second row is where most UK branch sites now land, and the reasoning is straightforward. Two independent consumer-grade-priced fibre circuits from genuinely different carriers, with an SD-WAN device steering across both, delivers better real-world availability than one leased line at roughly half the cost, provided the applications tolerate a brief reconvergence. The caveat is the word genuinely: two circuits resold by different providers over the same Openreach infrastructure into the same duct are one circuit with two invoices, and establishing actual physical diversity requires asking the supplier a direct question and not accepting a vague answer.
Leased lines retain a clear case where the requirement is a contractual availability figure with a service credit attached, where upstream throughput is heavy and sustained, or where the site depends on something that genuinely cannot reconverge. What has changed is that this is now a smaller set of sites than it was five years ago, and the default has shifted. The detailed comparison sits in our guide to leased lines against business broadband.
Do not omit the hub from the budget. A cloud hub with a VPN gateway, a firewall and its associated data processing is a standing monthly cost in the low hundreds to low thousands depending on the SKUs chosen, and it is a cost that exists once for the estate rather than per site. Spread across twelve branches it is modest; spread across three it is a significant proportion of the total, which is part of why the managed-hub model becomes more compelling as site count rises.
Addressing, routing and DNS
These three decisions are unglamorous, they never appear in a supplier pitch, and they cause more multi-site pain than every product choice combined.
Plan the address space once, for more sites than you have
Allocate from a single private range with a consistent scheme: a block per site, subnetted by function within the site so that the third octet or a bit pattern identifies the purpose. A common approach is to reserve a /16 for the estate and issue a /20 or /22 per site, which leaves enough room that no site ever needs a second discontiguous allocation and enough sites that acquisitions can be absorbed. The specific scheme matters far less than having one and applying it without exceptions.
Plan for at least double the current site count. The cost of reserving space you never use is nothing. The cost of running out is renumbering a live site, which is the most disruptive routine task in networking and the one most likely to break something nobody knew depended on an address.
Use dynamic routing once the estate justifies it
Static routes are perfectly adequate for three sites and become a liability somewhere around six, because every topology change means updating every device that holds a route, and a missed one produces asymmetric routing that works until it does not. BGP over the tunnels lets sites advertise their own prefixes and withdraw them when a path fails, which is what makes failover automatic rather than manual. Most current firewalls and SD-WAN platforms support it, and the configuration for a simple hub-and-spoke is not complex — the complexity people associate with BGP comes from internet-facing multi-homing, which is a different exercise.
Decide where DNS resolves, deliberately
Multi-site DNS fails in a specific and recognisable way: a branch resolves an internal name against a server it can no longer reach, or resolves a cloud private endpoint to a public address because a conditional forwarder was never configured. Decide explicitly which resolvers each site uses, how internal zones are reached from every location, and what happens to name resolution when the tunnel to the hub is down. Cloud platforms offer managed private resolvers that make this considerably tidier than the traditional approach of a domain controller in every comms room.
Set MTU and MSS correctly
IPsec encapsulation reduces the usable payload, and a path that leaves MTU at 1500 with no MSS clamping produces the classic intermittent failure: small requests work, large transfers and some web pages hang, and it takes a fortnight to diagnose because ping works perfectly. Clamping TCP MSS at the tunnel interface, commonly to around 1350–1400 bytes, avoids an entire category of support ticket. Most SD-WAN platforms handle this automatically; manually built tunnels frequently do not.
Acquisitions are where addressing plans go to die. An acquired business arrives with its own address space, its own domain, its own DNS and a very high probability of using the same 192.168.x.x range as one of your existing sites. Resolve the addressing question during due diligence rather than after integration has started, because the alternative is either a renumbering project nobody budgeted for or a permanent network address translation arrangement between the two estates that everyone agrees is temporary and which is still in place four years later.
The number that predicts whether a design will scale
If one measurement had to stand in for the whole design review, it would be the proportion of branch traffic whose destination is not head office. It determines whether backhauling is defensible, whether the hub needs to be large or small, and in practice whether the network was designed for the applications the business actually uses or for the ones it used a decade ago.
Seventy-eight per cent going to the cloud or the internet means that a design backhauling all branch traffic to head office is sending more than three quarters of it on a detour. The traffic leaves the branch, crosses to head office, is inspected, leaves through the head office circuit to the internet, and returns by the same path. The branch user experiences the latency of that round trip on every cloud interaction, and the head office circuit carries four times the traffic it would otherwise need to.
The fix is local internet breakout at the branch, with policy applied either on the branch device or by a cloud security service the branch sends traffic to. The objection raised is always inspection: if traffic does not come back to head office, what enforces the rules? The answer is that centralised policy and centralised routing are separable, as noted earlier. A consistent rule set pushed to every branch device from one controller provides the same enforcement without the detour, and a cloud-delivered security service provides it without requiring capable hardware at every site.
Where the figure is genuinely low — a manufacturer whose production systems all live in a data centre at the main site, for instance — backhauling is the correct design and the hub should be sized accordingly. The point is not that local breakout is always right. It is that the decision should follow a measurement, and in most organisations nobody has taken one.
Benchmarks — what good looks like against what we find
Adoption rates below are drawn from reviews of UK multi-site estates in the three-to-fifteen-site band. As with any adoption measure these are generous readings: a site counts as having failover if any secondary path exists, regardless of whether it has ever been proven to work.
Adoption of multi-site design practices in UK organisations
The gap between having a secondary circuit at forty-one per cent and having tested it at seventeen per cent is the most expensive line in that table. Untested failover fails in ways that are specific and predictable: the secondary circuit has been unplugged since the last office reshuffle, the failover works but the tunnel does not re-establish because the hub has an address restriction, or the path switches correctly and every voice call drops because nothing was configured to re-register. All three are found in minutes by a deliberate test and discovered at the worst possible time otherwise.
Twenty-six per cent on consistent per-site standards is the figure that predicts long-run operational cost. An estate where every site is built the same way can be supported by anyone with the runbook. An estate where each site reflects the preferences of whoever installed it requires site-specific knowledge for every change, and that knowledge lives in people rather than documents.
Multi-site readiness — where most UK estates sit
Combining the assessment areas into a single figure gives a rough indication of how well a multi-site network is positioned to absorb another site without a redesign. The gauge reflects a first review of a UK organisation running four or more locations that grew site by site rather than to a plan.
A score in the high thirties breaks down consistently. Connectivity itself usually scores reasonably, because circuits are the part that gets bought properly and UK fibre availability has improved considerably. Topology scores moderately, because something coherent usually exists even if it was not chosen. Addressing and documentation score badly, because both are invisible until they are urgent. Resilience scores worst, because it is the area where the gap between configured and proven is widest.
The useful property of a low score here is that the expensive remedies are rarely the ones that move it most. Writing an addressing plan costs a day. Testing failover at every site costs an afternoon each. Standardising the VLAN structure costs a decision. Moving to a cloud hub or an SD-WAN fabric costs real money and is worth doing, but an organisation at thirty-nine will get more improvement per pound from the documentation and testing items than from replacing hardware — and doing those first makes the hardware project shorter when it comes.
A caveat on the score, as with any benchmark: a three-site organisation with static routes, manual tunnels and no SD-WAN might score in the forties and be entirely well served by what it has. Small, stable estates do not need the machinery that a growing twelve-site estate needs. The score measures readiness to scale, and an organisation with no intention of scaling is entitled to disregard it.
Designing resilience across sites
Resilience in a multi-site network has three layers, and organisations commonly build one of them and assume they have all three.
Circuit resilience at the branch
A second path out of the building, ideally from a different carrier over different physical infrastructure. Where genuine physical diversity is unavailable or uneconomic — which is common in business parks and rural sites — a 4G or 5G service provides real diversity because the failure modes are unrelated, even though the capacity is lower and more variable. A modest cellular failover that keeps voice and email working is worth considerably more than a second fixed circuit sharing a duct with the first.
Device resilience at the branch
A second appliance at each site in a high-availability pair. This is where the cost-benefit turns sharply on site importance. For a branch of fifteen people where a four-hour hardware replacement is tolerable, a spare unit on a shelf at head office, preconfigured and ready to ship, delivers most of the benefit for a fraction of the cost. For a site where an outage stops trading, the HA pair is justified. Deciding this per site rather than as a blanket standard is what keeps the budget sensible.
Hub resilience
The layer most often missed, and the one with the largest blast radius. A single hub means every site depends on one location or one cloud region. Cloud platforms make the remedy relatively accessible: zone-redundant gateways within a region protect against a datacentre-level failure, and a second hub in a second region protects against a regional one, with branches holding tunnels to both and routing preferring the nearer. The second hub roughly doubles the standing hub cost, which is why it needs to be an explicit decision measured against what an estate-wide outage would cost rather than an assumption in either direction.
Underneath all three sits the point that resilience which has not been tested is a design intention. The test that matters is not a planned maintenance window at two in the morning — it is pulling the primary circuit during the working day with users on calls, and watching what happens. Organisations are reluctant to do this, understandably, and the reluctance is itself informative: a failover nobody is willing to test during business hours is one nobody actually trusts.
Voice is the workload that exposes weak resilience first, because it is the one users notice within seconds rather than minutes. A branch that fails over cleanly for email and web but drops every call has not achieved failover from the perspective of the people in the building. Sizing, marking and testing specifically for voice across the WAN is a distinct exercise, and it interacts with the choice of telephony platform — something we work through in our guide to choosing a VoIP provider and hosted PBX.
Common multi-site design mistakes
The failures below are the ones that recur across reviews. Most are not technical errors at the time they are made — they are reasonable decisions for the size the network was, left in place as it grew.
- Choosing the transport before the topology. Ordering circuits and appliances before deciding the shape of the network means the shape gets decided by what was bought. Reversing that order costs nothing and constrains nothing.
- Letting the head office remain the hub by default. Head office is a building on a lease with a circuit sized for the people in it. Making it the network core ties the estate to a location the business may want to change, and puts every branch behind one building outage.
- Backhauling internet traffic that has no reason to go to head office. With roughly four fifths of branch traffic bound for the cloud, backhauling adds latency to the majority of what users do and oversizes the head office circuit to carry it.
- Deferring the addressing plan. Address space is free to reserve and extremely expensive to reclaim. Every site added without a plan increases the cost of eventually writing one.
- Assuming two circuits means diversity. Two providers reselling the same infrastructure into the same duct is one circuit with two bills. Physical diversity has to be asked about specifically and confirmed in writing.
- Adding direct site-to-site tunnels without a recorded reason. Each one is defensible on its own and the accumulation is a mesh nobody designed. Requiring a named application before adding a path keeps a partial mesh partial.
- Treating SD-WAN as a capacity upgrade. It manages congestion intelligently; it does not remove it. Size the circuits for the workload first, then add the overlay to steer across them.
- Leaving per-site firewall rules to diverge. Rules added at individual sites over years produce an estate where the effective policy is unknown, which is both an operational and a certification problem.
The most costly version of the head-office-hub mistake surfaces during an office move. An organisation relocating head office discovers that the move is not an office move but a network core migration, with every branch tunnel needing to be re-pointed and a circuit lead time at the new building measured in months rather than weeks. If head office is currently your hub and a move is anywhere on the horizon, moving the hub to a cloud region first turns a critical-path dependency into an ordinary office relocation.
What this looks like in practice
A specialist distribution business operating from a head office in Birmingham with five regional depots had grown its network one site at a time over nine years. Each depot held an IPsec tunnel to the firewall at head office, and two of the depots had a direct tunnel to each other because a stock system had once required it. All internet traffic from every depot was backhauled to Birmingham and inspected there. The head office circuit was a 200 Mbps leased line that had been sized when the depots had eight people each.
The presenting problem was not an outage. It was that Teams calls at the depots had become unreliable, and that opening a sixth depot had taken the internal IT manager eleven working days spread over two months. Both complaints had the same cause, and neither was a bandwidth problem in the way it was first described.
The audit found what audits of this shape usually find. Two depots were using the same 192.168.1.0/24 range, which was why the stock system tunnel between the other two had been built the way it had — it was routing around a conflict rather than serving a requirement. Eighty-one per cent of depot traffic was destined for Microsoft 365 or the cloud-hosted ERP, all of it travelling to Birmingham and back out. The head office circuit was running at sustained high utilisation during business hours, which was the direct cause of the voice quality complaints at every depot including the ones with unused capacity of their own. No depot had a secondary circuit. The failover at head office had last been tested in 2022.
The redesign moved the hub into a UK Azure region, left head office as a spoke like any other site, and put an SD-WAN appliance at each depot with local internet breakout and a consistent policy set pushed from one dashboard. Two depots were renumbered over consecutive weekends. Each depot gained a second path, four using a second fibre provider and two using 5G where diverse fibre was not available at a sensible price. The head office leased line was retained but was now carrying head office traffic rather than the estate.
Voice complaints stopped, which was expected. The figure that interested the board was different: adding the seventh depot the following year took under a day, most of which was waiting for the circuit to be activated, because the appliance had been shipped preconfigured and joined the fabric when it was plugged in.
We had been told for two years that we needed a bigger line at head office. What we actually needed was to stop sending traffic there. The bandwidth was never the problem, the shape of the thing was, and nobody had stepped back far enough to see it because every individual decision that got us there had been perfectly sensible at the time.
The generalisable point is the one about the stock system tunnel. It had been documented as an application requirement and repeated as such for years, and it was actually a workaround for an addressing conflict that predated everyone in the current team. Multi-site networks accumulate this kind of fossil, and an audit that asks why each path exists — rather than recording that it does — is what separates a redesign from a re-implementation of the same network on newer hardware.
The 12-point multi-site network design checklist
Work through these in order. Items one to four are design decisions made on paper before anything is purchased. Items five to nine are the build. Items ten to twelve are what keeps the design intact as the estate grows.
- Build the traffic matrix from measured flow data. For every site, the proportion of traffic going to the internet or cloud, to head office, and to other branches. Measure it rather than estimating it; the estimate is usually a decade out of date.
- Choose the topology explicitly and write down why. Hub-and-spoke as the default, with direct spoke-to-spoke paths only where a named application and a measured latency requirement justify one.
- Decide where the hub lives. A cloud region for most new designs. If head office is currently the hub, treat moving it as a priority rather than a nicety, particularly if a relocation is possible.
- Write a single IP addressing plan covering at least double the current site count. One block per site, consistent internal subnetting, space reserved for acquisitions. Identify every overlap now.
- Define the standard branch build. Device model tiers by site size, VLAN structure, policy set, naming convention. One build applied everywhere, with variation by documented exception only.
- Size circuits for the workload, then choose the overlay. Capacity first, steering second. Two diverse fibre circuits with SD-WAN is the default for most UK branches; confirm the diversity is physical.
- Implement dynamic routing if the estate exceeds about five sites. BGP over the tunnels so that path changes propagate automatically rather than requiring a change on every device.
- Configure local internet breakout with centrally managed policy. Keep enforcement consistent across the estate without routing cloud-bound traffic through head office to achieve it.
- Set MTU and clamp TCP MSS on every tunnel. Around 1350 to 1400 bytes. This removes an entire class of intermittent fault that is very hard to diagnose later.
- Segment every site to the same VLAN standard. Corporate devices, guest, voice and building systems separated, with policy between them, applied during the rollout rather than retrofitted.
- Test failover at every site during working hours. Pull the primary circuit with users present and watch what happens to a live voice call. Repeat annually and after any change.
- Document the runbook for adding site n+1. The test of a good multi-site design is that the next site can be added from the document by somebody who was not involved in building the network.
Items one to four cost nothing but time and deliver most of the long-run value, because they are the decisions that are cheap now and expensive to revisit. An organisation that is not ready to invest in new hardware should still complete the traffic matrix and the addressing plan. Both remain valid whatever is eventually purchased, both shorten every future supplier conversation, and the addressing plan in particular prevents the specific problem that makes multi-site consolidations overrun.
At a glance — multi-site network design summary
| Question | Short answer |
|---|---|
| What should be decided first? | Topology, before transport, policy or products. It constrains everything downstream and is the hardest thing to change later. |
| Tunnels in a full mesh | n(n-1)/2 — 6 sites means 15 tunnels, 12 sites means 66 |
| Tunnels in hub-and-spoke | One per site. Twelve sites means twelve tunnels. |
| Default topology for most UK estates | Hub-and-spoke with a cloud hub, plus direct paths only where a named application requires one |
| Where should the hub live? | A cloud region for new designs. Head office as hub ties the network core to a building on a lease. |
| VPN or SD-WAN? | Manual IPsec is workable under about five stable sites; SD-WAN wins on operations, failover speed and per-application steering above that |
| Typical SD-WAN licence cost | £250–900 per site per year, on top of the circuits |
| Best-value UK branch connectivity in 2026 | Two genuinely diverse FTTP circuits with SD-WAN steering, roughly £150–260 per site per month |
| Branch traffic going to cloud or internet | Around 78 per cent, which is the case for local breakout rather than backhaul |
| Most common hidden blocker | Overlapping RFC1918 address space between sites — found on roughly half of first audits |
| When to move from static routes to BGP | Around five to six sites, or sooner if paths change regularly |
| MSS clamping value over IPsec | Approximately 1350–1400 bytes; prevents intermittent large-transfer failures |
| Typical UK inter-site latency | 6–9ms round trip on business fibre between mainland sites |
| Realistic consolidation timeline | About 16 weeks for 8–12 sites, with audit and renumbering the phases that do not compress |
How Cloudswitched approaches multi-site networks
Cloudswitched designs, builds and manages cloud networking for UK organisations operating across multiple locations. In practice that starts with the audit and traffic matrix rather than with a product recommendation, because the topology decision is the one that determines whether the rest of the investment is well spent. From there we cover the addressing plan, the hub design and its resilience, the standard branch build, the rollout in waves, segmentation to a consistent standard, and ongoing management with central monitoring of every circuit and tunnel. Where an internal team wants to run the estate themselves, we design it, build it and hand it over with the runbook for adding the next site.
Designing a network that scales past the next site
We review UK multi-site estates end to end — topology, addressing, resilience and policy — and design the shape that makes adding a location routine rather than a project.
Talk to a Cloud Networking SpecialistFrequently Asked Questions
What is multi-site network design and why does topology come first?
Multi-site network design is the set of decisions that determine how an organisation with more than one location connects those locations to each other, to shared systems and to the cloud. Topology — which sites talk to which, and through what — comes first because it constrains every subsequent decision and is the most disruptive thing to change afterwards. Transport can be swapped one site at a time without the rest of the network noticing. Policy can be relocated through configuration. Changing topology means re-pointing every tunnel on every device at once, which is a cutover weekend with a rollback plan for the whole estate. Deciding it deliberately at the start costs a day of thinking; deciding it by accident costs a project later.
Is hub-and-spoke or full mesh better for branch offices?
Hub-and-spoke for the overwhelming majority of UK businesses, with direct paths added only where justified. The arithmetic drives it: a full mesh needs n(n-1)/2 tunnels, so twelve sites means sixty-six tunnels to configure, monitor and maintain, against twelve in hub-and-spoke. The cost of hub-and-spoke is that branch-to-branch traffic transits the hub, and for most organisations branch-to-branch traffic is a very small share of the total because the shared applications now live in the cloud. Build the traffic matrix before deciding. If two specific sites genuinely need a direct low-latency path for a named application, add that one path — a partial mesh is usually the right answer, not a compromise.
Should we use site-to-site VPN or SD-WAN?
They are not competing transports; both run over the same circuits. Manual site-to-site IPsec is entirely workable up to around five stable sites where there are in-house network skills and sites are rarely added. SD-WAN becomes the better answer above that, and sooner if the business is opening locations regularly. What you gain is zero-touch provisioning, tunnels that build themselves, sub-second failover rather than tens of seconds, per-application path selection, and one dashboard showing the whole estate. What you pay is a licence, commonly in the range of £250 to £900 per site per year. The operational argument usually decides it before the technical one does.
Where should the hub be — head office or the cloud?
A cloud region, for almost all new designs. A head-office hub ties the network core to a specific building on a specific lease, sizes the head office circuit to carry traffic from the whole estate, and makes a head office outage an estate-wide outage. It also turns any future office relocation into a network core migration, which is a substantially larger undertaking than moving an office. A cloud hub sits adjacent to where most traffic is already going, scales by changing a SKU rather than by shipping hardware, and can be made zone-redundant far more cheaply than a second comms room can be built. Head office then becomes a spoke like any other site.
What is the most common hidden problem in a multi-site consolidation?
Overlapping private IP address ranges between sites. Several offices each set up independently with the default 192.168.1.0/24 causes no difficulty at all until those sites need to route to each other, at which point it cannot be configured around — it has to be renumbered. Renumbering a live site means DHCP scopes, static reservations and every device someone typed a fixed address into years ago: printers, access control, CCTV, building management. It is the single most common reason a consolidation takes three months rather than three weeks. Audit for it at the very start, because it sets the timeline for everything else.
Should branch internet traffic be backhauled to head office?
Usually not. Around seventy-eight per cent of branch traffic is now destined for the internet or a cloud platform, so backhauling sends more than three quarters of it on a detour to head office and back, adding latency to most of what users do and requiring the head office circuit to carry traffic for the whole estate. The usual objection is inspection, but centralised policy and centralised routing are separable: a consistent rule set pushed to every branch device from one controller, or a cloud-delivered security service, enforces the same policy without the detour. Backhauling is correct where the applications genuinely live at the main site, which is a smaller set of organisations than it used to be.
How much does connecting a branch office cost in the UK?
Indicatively, in 2026 and excluding VAT and installation: FTTP business broadband with an IPsec tunnel runs about £45 to £90 per month; two diverse FTTP circuits with SD-WAN, which is the value sweet spot for most branches, about £150 to £260 including the licence; an uncontended symmetric leased line about £280 to £650; and 4G or 5G with an SD-WAN device about £60 to £140. Leased line pricing in particular varies widely by postcode and distance to the nearest point of presence, so these are budgeting figures rather than quotations. Remember to budget the hub separately — it is a standing estate-wide cost rather than a per-site one.
Do we need a leased line at every site?
Rarely. Leased lines retain a clear case where a contractual availability figure with service credits is required, where sustained upstream throughput is heavy, or where a site depends on something that cannot tolerate reconvergence. For most branches, two independent fibre circuits from genuinely different carriers with SD-WAN steering across them delivers better real-world availability at roughly half the cost. The critical word is genuinely: two services resold over the same infrastructure into the same duct are one circuit with two invoices, and physical diversity has to be asked about directly rather than assumed from the fact that there are two suppliers.
When should we move from static routes to BGP?
Around five to six sites, or earlier if paths change regularly. Static routes are fine for three sites and become a liability as the estate grows, because every topology change requires updating every device holding a route, and one missed entry produces asymmetric routing that works until the day it does not. BGP over the tunnels lets each site advertise its own prefixes and withdraw them when a path fails, which is what makes failover automatic rather than a manual intervention. The configuration for a straightforward hub-and-spoke is not complicated; the complexity people associate with BGP comes from internet-facing multi-homing, which is a different problem.
Why do large file transfers fail over our site-to-site VPN when ping works?
Almost always MTU. IPsec encapsulation reduces the usable payload, and if MTU is left at 1500 with no MSS clamping the result is the classic pattern: small packets pass, large transfers and some web pages hang, and diagnosis takes far longer than it should because basic connectivity tests all succeed. Clamping TCP MSS at the tunnel interface, typically to somewhere around 1350 to 1400 bytes, resolves it. Most SD-WAN platforms handle this automatically; manually built tunnels between firewalls frequently do not, which is why it shows up on VPN estates far more often than on managed fabrics.
How long does a multi-site network consolidation take?
About sixteen weeks for eight to twelve sites where the sites are reasonably straightforward and somebody is dedicated to the work: two weeks of audit and traffic analysis, a week on topology and addressing, two weeks building and testing the hub, three weeks of renumbering where needed, four weeks migrating sites in waves, then segmentation, resilience testing and documentation. The migration waves compress with more hands. The audit and renumbering phases do not, because both are bounded by discovery rather than effort — an undocumented static IP address is not found faster by assigning two people to look for it.
How do we stop the design degrading as we add sites?
Three things. Define a standard branch build — device tiers by site size, VLAN structure, policy set, naming convention — and allow variation only by documented exception. Require a named application and a measured requirement before any direct site-to-site path is added, which is what keeps a partial mesh from quietly becoming a full one. And write the runbook for adding site n+1, then have somebody who was not involved in the original project use it. An estate degrades through reasonable individual decisions accumulating without a standard to check them against, so the standard is the control, not the technology.
Related reading
More guidance on planning and running UK business networks, connectivity and cloud infrastructure:
A network shaped for where it is going
Cloudswitched audits UK multi-site estates, builds the traffic matrix and the addressing plan, and designs the topology, hub and branch standard so that opening the next location is a routine task rather than a project.
Talk to a Cloud Networking Specialist
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
