InsightNetworkingMulti-Site Operations

Most multi-site networks were not designed. They accumulated.

The network you have today is the network nobody planned. Each new site added a router, a firewall, a contractor, a configuration choice. None of it was wrong on the day it was made. None of it has been reviewed since.

In multi-site organisations, network risk usually appears as drift: inconsistent hardware, firewall rules, support ownership, monitoring, firmware and failover across branches. The first step is not choosing SD-WAN or SASE. It is understanding what is actually deployed, where the weak points sit, and which sites matter most to operations.

Site by site / drift / current state
NETWORK SITESSUPPORTEDGE Standardised Edgedocumented modelBranch NetworkRemote SitesUnmanaged Driftno visibilityRISKRISKRISKRISK VISIBILITY GAP
RealityBranch sprawl accumulates
SupportA documented support model
VisibilityOperational and cyber
EdgeEngineering-led standardisation
Where the drift actually sits

Three questions that explain where the drift actually sits.

Drift is the gap between the network you would design today and the network you actually have. Three questions explain how it builds, why leaders miss it, and what separates a working network from a well-run one.

01

What does multi-site network drift actually mean?

Drift accumulates over time as new sites are added, contractors come and go, vendors change, and configurations get tweaked for reasons no one remembers. The network usually keeps working. The risk is that no one can describe what it is, who manages each piece, or what would happen if a single edge device failed at the busiest site.

ThemeAccumulation
02

Why do business leaders miss network risk until something breaks?

Networks are usually invisible when they work, and the threshold for noticing is only crossed at failure. Performance issues get attributed to busy days, outages to bad luck, and the cumulative cost rarely shows up as a line item in the management report. It remains a blind spot until a single event makes it obvious.

ThemeBlind spot
03

Working network, well-run network. What is the difference?

A working network carries traffic most days. A well-run network can be described, monitored, patched, supported and recovered consistently across sites. Most multi-site organisations have the first kind. The second takes deliberate engineering, not just piecemeal accumulation.

ThemeOperating standard
The accumulation

Networks rarely fail because one decision was wrong. They fail because growth outpaced standardisation.

A working network
  • Carries traffic most days
  • Grew one site, one supplier at a time
  • Five years in fifteen sites, four firewall vendors, three VPN topologies
  • Support varies by who was available at go-live
A well-run network
  • Can be described, monitored and patched
  • Supported and recovered consistently across sites
  • Evidence ready for the insurer and procurement
  • Built by deliberate engineering, not piecemeal accumulation
New site
New router
New firewall
New contractor
Never reviewed

None of it was wrong on the day it was made. None of it has been reviewed since.

What drift looks like

Six patterns that commonly show up in multi-site network reviews.

None of these are exotic. All of them are common. Most multi-site organisations have at least three of the six. None on its own is critical. Together they describe a network that has accumulated rather than been engineered.

Pattern 01 · Vendor sprawl
The patternThree or more firewall vendors across the network, each with its own management interface, update cycle and quirks.
In practicePolicies drift between platforms, engineers who can confidently work across all of them are scarce, and each new site uses whatever the local installer preferred.
Pattern 02 · Configuration drift
The patternFirewall rule sets differ from site to site without documented reasons.
In practiceA one-off exception that became permanent, a workaround for a problem fixed three years ago, or a setting nobody remembers configuring. Invisible until someone tries to standardise.
Pattern 03 · Support model fragmentation
The patternDifferent sites are supported by different parties, with no consistent SLA.
In practiceHead office sits with the primary MSP, two regional sites use a contractor who stopped responding six months ago, and branch IT becomes a question of who happens to be available, not a defined operating model.
Pattern 04 · Inventory absence
The patternNo current map of what is at each site, who manages it, what version it runs.
In practiceProcurement has serial numbers, the IT team has approximate counts, the on-site contractor knows what is actually there. Producing a current edge-device inventory takes weeks, not days — which is itself the diagnosis.
Pattern 05 · Lifecycle drift
The patternBranch hardware approaching or past end-of-life with no refresh plan.
In practiceEnd-of-support dates pass without anyone noticing. The first signal is usually a security advisory the vendor will no longer patch, by which point at least one site is running unsupported infrastructure.
Pattern 06 · Visibility gap
The patternMonitoring and alerting works at head office, less consistently elsewhere.
In practiceBranch monitoring is partial, alert thresholds vary, and outages at smaller sites are sometimes noticed by on-site staff before the IT team. Performance degradation goes unmeasured, which means it goes unfunded.

Drift is a measurable cyber risk. A 2024 Kaspersky survey of geographically distributed businesses found 62 percent identified a disparity in cyber protection across all sites, with branches typically more exposed than head office. Attackers do not need the head office to be the weak point — a branch with weaker patching, looser edge controls or poorer visibility can become the entry point for a wider incident.

Why leaders miss it

The reasons drift stays invisible until something specific surfaces it.

CFOs, COOs and general managers do not miss network risk because they are not paying attention. They miss it because the systems are technical, the costs are diffused, and the language IT teams use does not translate to the management report. All of these tend to be true at the same time, which is why drift compounds quietly.

How the cost hides
01

Busy days

Performance issues get attributed to busy days, not infrastructure problems that have been growing for months.

02

Bad luck

Outages get attributed to bad luck, not the absence of redundancy or monitoring.

03

No line item

The cumulative cost of degradation does not appear on a single line in any management report.

04

Nothing has broken yet

Which is exactly when investment in invisible improvement is hardest to justify.

Why it stays unowned
05

Branch IT sits with whoever is closest

Often not with the IT team that owns the platform.

06

No design review at new sites

The procurement process for a new site rarely includes a network design review.

07

IT lacks current visibility

The IT team itself may not have current visibility, which means leadership cannot get current answers.

08

Due diligence is now asking

Insurance and customer due diligence increasingly ask for clearer evidence of edge security, remote access and network segmentation.

What a review examines

The six things a multi-site network review actually checks.

A network review is not an SD-WAN sales pitch. It is a current-state map plus a prioritised list of work. The output is what the management team needs to make decisions: where the gaps are, which gaps matter most, and what closing them actually involves.

A network review is the input. SD-WAN, SASE, branch standardisation and managed network support are possible outputs, depending on what the review actually finds. Skipping the diagnostic step and jumping straight to deployment is how organisations end up with a rollout that delivered fewer of the promised benefits than expected.

Review
Edge inventory
Current devices by site, vendor, model and firmware version.
Policy consistency
Firewall rule sets compared across sites, with reasons for variation.
Patch and firmware status
Current versions, support status, known vulnerabilities by device.
Support model documentation
Who manages each site, who escalates, what the SLA actually is.
Monitoring and visibility
What is monitored, what alerts trigger, where the gaps are.
Resilience and failover
Connectivity redundancy and recovery capability at branch level.
The Inlight IT view

Multi-site networks need visibility before platform decisions.

Multi-site networks drift because businesses grow faster than network standards are reviewed. It becomes a risk when the organisation can no longer describe what is deployed at each site, who owns changes, which rules are exceptions, what is monitored, and which sites would be materially affected by a link or edge-device failure. Inlight IT's view is that the starting point is not SD-WAN, SASE or a new firewall platform — it is a current-state review. Inlight IT runs network reviews and operates the resulting architecture as part of cyber-first managed services for Australian businesses.

The first step is not SD-WAN or SASE. The first step is knowing what you actually have.

01

Start with the current-state review

02

Standardise where inconsistency creates risk

03

Replace hardware where exposure is material

04

Improve monitoring where teams are blind

Delivery

A network review delivered inside an accountable engineering-led operating layer.

The argument on this page — that multi-site networks accumulate without being designed, that drift is a measurable risk, and that the first step is current-state visibility rather than platform selection — describes how Inlight IT delivers a Network Review: the diagnostic foundation that informs standardisation, SD-WAN, SASE, branch firewall refresh or managed network support.

Network Review

The first thing to know about a multi-site network is what you actually have.

Review edge devices, firewall policy, failover and ownership across every site. Scoped to your environment — Inlight IT remains the accountable service owner throughout.

Discuss Network Review