Multi-Site Networks: Connecting Branches, Central Management and Outage Backup
| Enterprise Networks
One shop online does not mean every shop online. Branch interconnection, central management, permissions and backup — how to keep every branch stable while head office keeps oversight.
Introduction: One Shop Online Does Not Mean Every Shop Online
Many Hong Kong companies grow from one shop to two, three, or many locations: branches, warehouses, offices, workshops, temporary stalls. Each branch gets its own broadband and its own Wi-Fi, and on the surface everything is online — but real problems appear quickly: files between branches travel through personal channels, head office cannot see branch network status, a branch outage goes unnoticed, till systems each do their own thing, and staff visiting another branch have to be set up again from scratch.
The point of a multi-site network is not that each branch has internet — it is that many locations are managed as one network. This guide starts with architecture choice, then covers branch interconnection, central management, permissions, segmentation and backup, and finishes with rollout steps and an acceptance checklist.
Three Architecture Options: State the Needs First, Then the Technology
There is no one multi-site architecture that suits every company. Before deciding, inventory: how many locations, what each location does (till, office, warehouse, workshop), how many people and devices each has, what must travel between locations (files, till data, CCTV, phones), which systems must sync immediately, and which can wait.
| Architecture | Approach | Suits | Watch Out For |
|---|---|---|---|
| Independent sites plus cloud systems | Each location online independently; systems hosted on a cloud platform | Branches that do not need to connect to each other directly, mainly using cloud systems | Each location's network quality directly affects cloud-system performance; branch management needs separate arrangements |
| Site-to-site interconnection | Encrypted connections between locations, linking them together | Branches that need direct access to head-office systems, shared files, internal phones | Each location needs setup and maintenance; as locations grow, management complexity grows too |
| SD-WAN-style central management | Centrally managed network equipment with unified policy and unified monitoring | Many locations, a wish to manage uniformly, and a wish for head office to see every location's status | Equipment and platform must work together; central policy must be designed in advance, not one policy per location |
The three options are not mutually exclusive and can be combined: cloud systems plus site-to-site interconnection, or site-to-site interconnection plus central management. The key is not to treat buying a particular device as having built a multi-site network. Architecture follows needs, not products. For office-network fundamentals, see our office network page; for remote-work connections, see our remote-work VPN guide.
Branch Interconnection: What Must Connect, and What Must Not
Interconnecting branches is not a case of connecting everything. The more that is connected, the wider the blast radius. The practical approach is to connect by need:
- Must connect: till systems reaching head office, files reaching head-office servers or the cloud, phone systems working across sites, CCTV viewable from head office. This is production traffic and should be given priority.
- Need not connect: guest Wi-Fi, visitor networks and smart devices should not travel through the interconnection to head office. This traffic should go straight to the internet locally, not consume interconnection bandwidth.
- Must be segmented: each branch still needs internal segmentation — till, office, guest and CCTV each going their own way, not mixed because the branch is small. For restaurant-branch segmentation, see our restaurant / cafe Wi-Fi guide.
Interconnection traffic must be prioritised. Till and phone traffic has high immediacy requirements; file synchronisation can be scheduled; CCTV upload should be arranged by need. Without prioritisation, all traffic competes for the same connection and the till suffers at busy times.
Central Management: Unified Policy, Unified Monitoring, Unified Updates
Unified Policy: Not One Policy Per Branch
The most common multi-site mess is each branch having its own setup: different passwords, different segmentation, different Wi-Fi names, settings nobody knows. Staff visiting another branch have to ask for passwords and be set up again; when something goes wrong at head office, nobody knows how each branch is configured. The first step in central management is unified policy: Wi-Fi naming, segmentation, password management, access permissions and guest processes, all to one standard — not one invention per branch.
Unified Monitoring: Head Office Must See Every Branch's State
The second step is visibility. Head office should see each location's connection state, device state, traffic anomalies and outage alerts. Without visibility, there is no management: a branch outage goes unnoticed, and a stopped till is only discovered when the branch phones in. Monitoring does not need to be complicated, but it needs: which location is down, when it went down, how long it has been down, and who follows up. Alerts must reach the right people — not all go to one mailbox nobody reads.
Unified Updates: Firmware and Settings Need Someone Responsible
The third step is updates. Network-equipment firmware, settings and security policy need someone following them regularly — not each branch waiting until there is time. Back up before updating, verify after updating, and do not update every location at once — if something goes wrong, everything stops together.
Permissions: Head Office, Branch, Staff — Who Sees What
Multi-site network permissions need three layers:
- Head-office management: can see the state of all locations and the business systems they need, but should not unnecessarily reach every branch's full internal data.
- Branch managers: can run their own branch's day-to-day work, but should not be able to change other branches' settings or reach head-office sensitive systems.
- General staff: reach only the systems their work needs. When staff help at another branch, permissions should follow the person, not the location — visiting another branch should not automatically grant extra permissions.
Permissions need regular review: when staff leave, move branches or change roles, permissions must change with them. Avoid shared accounts — one account per person, so incidents can be traced. For account-security practice, see the identity-verification discussion in our remote-work VPN guide.
Backup: A Branch Outage Must Not Mean a Branch Shutdown
Branch outages are the most common multi-site incident. Backup needs two layers of thinking:
- Branch layer: when a branch's internet connection drops, what happens to the till, ordering and phones? Does the branch have a second way online, is switch-over automatic, and do staff know the process? Backup must be tested in practice: cut the main link, confirm the backup genuinely takes over and the till genuinely keeps working.
- Head-office layer: when head office drops, what happens to each branch? Can branches operate independently for a while, or does a head-office outage stop everything? This must be decided during architecture design, not discovered during an outage when every location depends on one head-office point.
Backup is not having a second line. Whether the second line has been tested, whether switch-over is automatic, whether bandwidth after switch-over is enough for the till, and whether staff know they have switched to backup — all must be verified. For enterprise-broadband backup thinking, see our business broadband guide.
Opening a New Branch: Use the Same Standard, Not a Fresh Design Every Time
Opening a new branch is when multi-site networks most easily fall into disorder. Rushing to open, the network is done roughly, and later it turns out not to fit the other branches. The practical response is a prepared new-branch network standard pack:
- Equipment list: which equipment, models and settings each branch uses — fixed in advance, not a different purchase per branch.
- Settings template: segmentation, Wi-Fi names, password policy and permissions, all from a template — new branches follow the template rather than reinventing it.
- Survey process: survey the new branch before opening — confirm coverage, cabling, power and placement. Do not discover on opening day that there is nowhere to mount an AP or no cable point.
- Acceptance checklist: accept each new branch item by item before opening — never just open and hope. The acceptance checklist should be the same as for existing branches.
New-branch networking must also fit the fit-out and opening timetable. Network work should run alongside the fit-out, not be left to the day before opening. For overall enterprise Wi-Fi planning, see our Wi-Fi solutions page; for IT support arrangements, see our SME IT support page.
Acceptance Checklist
| Acceptance Item | How to Test |
|---|---|
| Interconnection | Each location tries the head-office systems it should reach; systems it should not reach are confirmed unreachable |
| Segmentation | Guest devices in each branch try till and office systems and cannot reach them |
| Central monitoring | Head office confirms it can see every location's state; simulate one branch outage and confirm the alert reaches the right person |
| Permissions | Accounts of different roles try systems and confirm they see only what they should; cross-branch permissions tested specifically |
| Backup | Cut the main link in each branch and confirm the backup takes over and the till keeps working |
| New-branch template | Confirm the new-branch standard pack is complete so opening a branch needs no fresh design |
Common Misunderstandings
- Does broadband in every branch equal a multi-site network? No. Each site online independently is just independence. A multi-site network is managed as one network: unified policy, unified monitoring, unified permissions.
- Is connecting everything best? No. The more that is connected, the wider the blast radius. Guest Wi-Fi and visitor networks should not travel through the interconnection to head office.
- Does buying central-management equipment equal central management? No. Equipment is only a tool — policy, monitoring, updates and permissions all need people to design and follow them.
- Does having a backup mean outages never stop the shop? No. A backup counts only if its switch-over has been tested; an untested backup may not take over when the outage happens.
- Can a new branch just copy an old branch? No. Survey the site first — each branch's structure, coverage and cabling differ, and copying wholesale does not work.
Documentation: The Map Every Branch Shares
Multi-site networks fail quietly when nobody knows how they are built. Keep one living document per location — a simple map showing the equipment, the segments, the cable points, the passwords' storage location, and who is responsible — and one central register listing every location. When a branch changes anything, update both documents the same day. A network that only one person understands is a network that stops when that person is away.
Conclusion: Manage It as One Network, Not Many Independent Networks
Doing multi-site networking well comes down to three sentences: architecture must follow needs, not products; policy, monitoring and permissions must be unified, not one set per branch; backup must be tested, not assumed from having a second line. Our team first learns how each location's business and systems actually work, then recommends a solution for the real situation.