Most multi-site networks do not fail one link at a time. They strain because the design grew site by site, and the operating model never caught up
A link added here, a firewall there, a carrier renewed, a Microsoft 365 path left to drift — nothing looks broken in isolation, but the network becomes harder to operate. Managed SD-WAN gives multi-site organisations one network model across sites, cloud, applications and security, designed and operated around the environment itself.
- Architecture before platform, before carrier
- Design, deployment and managed operation
- Proven to a national 110+ site rollout
The situations that make a site-by-site network model harder to defend.
SD-WAN is often discussed as a way to improve performance or reduce carrier cost. The stronger reason is usually operational: the network still works, but it no longer feels clean enough to run across every site. Select a situation to see what is usually behind it.
Managed SD-WAN turns branch connectivity into an operating fabric.
The same sites, two ways to run them. Switch between them and watch the paths, cloud routing, failover and visibility change.
Traditional WAN design often grows around links and locations. Managed SD-WAN needs to be designed around how the organisation operates: which sites matter most, which applications are critical, how cloud traffic should move, where security inspection belongs, how failover should behave, and who owns the environment when something changes. SD-WAN is not a device at each site. It is the operating layer across underlays, routing, firewall policy, cloud access, monitoring and carrier escalation.
A properly managed SD-WAN environment should make the network easier to understand, not just faster. It should give internal IT clearer visibility across sites, reduce dependence on one carrier model where that no longer makes sense, help new sites come online in a more repeatable way, and give the organisation a cleaner path toward SASE or Zero Trust access where that is appropriate.
Site criticality decides the underlay, not the other way around.
SD-WAN improves how traffic is routed across available paths, but the quality of those paths still matters. A weak underlay does not become strong because it is connected to SD-WAN. Different site types need different underlay mixes.
Head office, primary sites and latency-sensitive workloads, where an eSLA and consistent throughput justify the cost.
Sites that must stay connected through a carrier fault, where a second diverse path protects continuity during degradation.
Smaller branches, project offices and pop-up sites that need to come online quickly without waiting on fixed-line provisioning.
Remote and regional locations where fixed-line options are limited, connected into the same managed policy as every other site.
The decision should be architectural before it is commercial.
MPLS does not always need to be removed immediately. In some environments it still has a role during transition or for specific workloads. In others, the business is paying for a WAN model that no longer matches cloud usage. The better question is not "should we replace MPLS?" but where each site sits.
- Sites with hard latency or private-transit requirements still in contract
- Workloads that depend on predictable point-to-point performance
- Locations where transition risk outweighs the near-term benefit
- Sites where traffic has moved to Microsoft 365, SaaS and Azure
- Branches paying for private transit they no longer use
- Locations where NBN EE, fibre or 4G/5G now meet the requirement
Proven at national scale, operating 110+ sites as one managed network.
The clearest proof is scale. Beijer Ref runs a national branch and commercial environment across every Australian state. Inlight IT replaced fragmented, site-by-site connectivity with a single managed SD-WAN fabric, delivered as a staged rollout, then operated after go-live rather than handed back.
A network is judged by how it runs afterwards, not by go-live.
A successful rollout is not measured only by whether the devices are online. It is measured by whether the network becomes easier to operate after the change.
Sites, carriers, underlays, routing, firewalls, VPNs, cloud access, Microsoft 365 paths, application dependencies, documentation and support responsibilities. This identifies what should be preserved, changed, and not carried forward.
The SD-WAN design is shaped around site criticality, application use, cloud access, security policy, failover expectations and operating responsibility. Not every site needs the same underlay, but every location needs a design that can be supported consistently.
Unclear firewall rules, unsupported hardware, poor documentation, weak failover, exposed management access or carrier ambiguity are addressed before cutover. Migrating those into a new fabric usually makes them harder to unwind later.
Rollout is staged by site, region, risk or business priority. Cutover planning, communication, testing and rollback are part of the work, so the change itself does not become the business interruption.
After deployment the environment needs ongoing monitoring, alert review, carrier escalation, policy management, documentation, lifecycle planning and change control. The operating discipline is what keeps the network reliable and supportable.
Network architecture handled by engineers who understand the environment around it.
SD-WAN sits between networking, security, cloud, carriers and day-to-day operations. Treating it as a device rollout creates avoidable problems. Inlight IT approaches SD-WAN as an operating layer across the environment.
01Engineering-led, not carrier-led
Carrier services matter, but the network should not be designed only around what a carrier wants to sell or renew. The design starts with site criticality, application paths, security policy, underlay options and the support model, then the carrier conversation happens against a clear architecture.
02Security and networking considered together
Firewall policy, secure internet breakout, segmentation, VPN, ZTNA and future SASE readiness are part of the SD-WAN conversation. They are not bolted on after the routing design is finished.
03Vendor fit before vendor preference
Fortinet, Cisco Meraki and other SD-WAN platforms can all be appropriate. The decision should reflect the environment, not a product default or an existing partnership. For organisations already on FortiGate, the Fortinet SD-WAN pathway goes deeper.
04Managed operation after deployment
A network can be well deployed and still become difficult to operate if visibility, documentation, lifecycle and escalation are not maintained. Inlight IT stays with the operating layer, not only the rollout, across a 110+ location national environment and smaller multi-site environments alike.
Recent multi-site network work
One national SD-WAN fabric, and the secure-access evolution of a multi-site network. Different problems, the same discipline of operating the network after go-live.
Questions that come up before a Managed SD-WAN conversation starts.
What happens in a Managed SD-WAN scoping conversation?
A scoped review of the current network position: sites, underlays, carriers, firewalls, cloud access, Microsoft 365 performance, failover, support responsibilities and current pain points. The outcome is a clearer view of whether SD-WAN is the right next step, what the architecture should consider and what a staged deployment would involve.
Is Managed SD-WAN the same as buying SD-WAN hardware?
No. Hardware and licensing are only part of the service. Managed SD-WAN includes architecture, underlay planning, carrier decisions, security integration, migration sequencing, monitoring, documentation and ongoing operation. Hardware alone does not produce a supportable network.
Can SD-WAN improve Microsoft 365 and Teams performance?
Often, yes. Many branch performance issues come from poor traffic paths rather than insufficient bandwidth. SD-WAN can support better application steering and direct cloud access, provided security policy and inspection are designed properly. Where the underlay or firewall design is the actual constraint, SD-WAN exposes that more clearly rather than hiding it.
Does SD-WAN replace MPLS?
Sometimes. MPLS may be removed, reduced, retained temporarily or kept for specific workloads. The right answer depends on contracts, site criticality, application dependencies, underlay quality and risk tolerance. The decision should be made against the architecture, not against the renewal date.
What underlays can SD-WAN use?
SD-WAN is underlay-agnostic. It can use NBN Enterprise Ethernet, business fibre, broadband, 4G/5G, satellite and MPLS. Different sites may need different combinations depending on availability, performance, resilience and business impact.
Is Fortinet SD-WAN the right platform?
It can be, especially where FortiGate firewalls are already in place or where firewall and SD-WAN operation should sit in one environment. It is not automatic. Fortinet should be selected because it fits the architecture, security requirements and operating model, not because it is the existing vendor.
How disruptive is an SD-WAN rollout?
A well-planned rollout should be staged and controlled. Site grouping, testing, cutover planning, rollback and communication reduce disruption. The 110+ location Beijer rollout was completed without operational disruption because the change was staged, tested and controlled. That is the standard the planning should be built around.
Do we need SASE as well as SD-WAN?
Not always. SD-WAN addresses connectivity, application paths and branch network control. SASE addresses secure access and cloud-delivered security controls around users, devices and applications. Some organisations start with SD-WAN and move toward SASE later. Others need both considered together.
Can Inlight IT manage SD-WAN after deployment?
Yes. Managed operation is part of the service: monitoring, policy management, carrier escalation, documentation, lifecycle planning, change control and ongoing review. Deployment without operating cover is where SD-WAN environments most often drift.