SD-WAN configuration is the easy part. The deployment is where it fails.
SD-WAN deployment is often described as a network modernisation project. In practice, it is a coordination exercise across architecture, carriers, underlays, firewall policy, application paths, rollout sequencing and managed operation. The hardware configuration is rarely the hardest part. For Australian multi-site organisations, the critical path is usually earlier: site audits, underlay availability, NBN Enterprise Ethernet or fibre lead times, 4G/5G coverage, MPLS contract timing, application dependency mapping, firewall integration, rollback planning and who owns the environment after go-live. A good SD-WAN deployment does not start with a platform choice. It starts with the current WAN, the sites, the applications, the underlays, the security model and the operating commitment required after deployment.
See the deployment phasesSD-WAN provider models; underlay options for Australian sites across NBN Enterprise Ethernet, business fibre, 4G/5G and Starlink; deployment phases and sequencing; MPLS migration economics and decommissioning; platform fit across Fortinet, Cisco Meraki and VMware VeloCloud migration; security integration and direct internet breakout; and managed operation after go-live. Written for Australian multi-site organisations planning or reviewing an SD-WAN deployment.
The hardware is the simple part.
SD-WAN deployment is not circuit replacement. It coordinates multiple workstreams at once: site audits, multi-carrier underlay procurement, application policy design, firewall and security integration, rollout sequencing, rollback planning and ongoing management. The hardware configuration is usually the simplest part.
For a multi-site Australian organisation, three workstreams should start in parallel from week one:
The current WAN is documented before anything is recommended: site connectivity, ISP arrangements, security policy, application performance, MPLS contract position, renewal dates and existing support responsibilities. This work establishes what should be preserved, what should change and what should not be carried into the new design.
The right access technology is confirmed per site: NBN Enterprise Ethernet, business fibre, 4G/5G, Starlink, retained MPLS or a mixed model. This has to happen early because NBN and fibre lead times can become the project critical path. In many Australian zones, NBN and fibre installs take 6 to 18 weeks. Procurement that begins after design sign-off can delay the whole rollout.
The deployment should define who owns SD-WAN policy, firmware, monitoring, ISP escalation, incident response, reporting and optimisation after go-live. A network that is successfully deployed but not actively operated can drift back into the same complexity the SD-WAN project was meant to reduce.
The provider model determines who owns the architecture after go-live.
Most organisations evaluating SD-WAN will encounter three provider models. They can all be valid in the right environment, but they create different accountability, security and operating outcomes.
A telco or carrier delivers SD-WAN as a network product. This model is usually built around the carrier's own network. Underlay options are limited to what that carrier can supply at each site. It can work where the organisation mainly wants a simpler circuit replacement and does not need carrier-agnostic sourcing, security integration or deeper operating management.
The limitation is ownership. Carrier-managed SD-WAN often stops at connectivity and overlay. Firewall policy, lifecycle management, performance optimisation and multi-carrier coordination may sit elsewhere. That creates the split-vendor problem: one party owns the network, another owns the firewall, and incidents that cross both domains become harder to resolve.
Best fit: organisations that want simple circuit replacement and are comfortable with a carrier-led operating model.
Hardware and licensing are purchased directly, and the organisation designs, configures and operates the SD-WAN environment. This model gives maximum control and flexibility, but it assumes internal SD-WAN engineering capacity. The internal team owns architecture, deployment, application policy, firewall integration, firmware, monitoring, carrier escalation, incident response and reporting.
It can be the right model for organisations with dedicated network engineering teams and the capacity to operate the platform properly after go-live.
Best fit: organisations with internal WAN engineering depth and the appetite to own ongoing operation.
Design, deployment and operation are delivered as one engagement. The architecture is built for the environment, not a carrier template. Underlays can be sourced per site across carriers. Network and security are designed together. The operating model is defined before go-live, with clear ownership for monitoring, ISP escalation, firmware, application policy and ongoing improvement.
This model suits organisations that do not have deep internal WAN engineering capacity and need the deployment and managed operation to sit with one accountable team.
Best fit: multi-site organisations that need architecture, cutover and ongoing operation handled as one managed service.
SD-WAN is the intelligence layer. The underlay is what it works with.
SD-WAN can make better use of available paths, but it cannot turn a weak underlay into a strong one. Each site should be assessed independently, then matched to the right access technology. The strongest SD-WAN design is not necessarily the one that uses a single carrier everywhere. It is the one that gives each site the right mix of performance, resilience, availability, cost and deployment timing. A carrier bundle can be easier to buy. It may not be the best technical fit for every site. A carrier-agnostic underlay design can use whichever carrier, RSP or access method gives the best outcome at each location.
NBN Enterprise Ethernet provides dedicated fibre-grade connectivity over NBN Co infrastructure. It offers symmetrical speeds, a dedicated connection and business-grade service levels backed by NBN Co. It can be a strong primary link for branch offices and regional sites where a direct fibre build is not commercially viable but consistent throughput matters. It carries a formal eSLA uptime commitment and integrates cleanly with SD-WAN policy-based routing and failover.
Best fit: branch offices and regional sites where direct fibre is not viable but consistent throughput is important.
Business fibre or dark fibre is usually the strongest primary link for high-throughput, low-latency sites. For head offices, data-centre-connected sites and locations with high application demand, dedicated Ethernet or dark fibre can provide the strongest baseline. It should be sourced across carriers such as Telstra, Optus, TPG, Vocus and competitive providers to find the best technical and commercial fit per site.
Best fit: head offices, data-centre-connected sites and high-workload locations requiring guaranteed throughput.
4G and 5G are fast-to-deploy backup options and, in some cases, viable primary links. Wireless has matured enough to be a genuine connectivity option for lower-bandwidth sites and a strong failover path at many locations. There is no civil works lead time. SD-WAN can manage failover automatically, moving traffic to wireless when a fixed line has an issue. Coverage should be assessed across Telstra, Optus and TPG before selecting the right SIM or wireless provider per site.
Best fit: failover at fixed-line sites, temporary or immediate connectivity for new locations, and primary connectivity for lower-bandwidth sites where fixed options are limited.
Starlink can provide connectivity for remote sites, construction environments, rural depots and locations beyond fibre or mobile coverage. Where no fixed-line option is available, Starlink can operate as a primary or secondary SD-WAN underlay. SD-WAN policy should account for latency-sensitive applications, traffic prioritisation and failover behaviour when satellite is used.
Best fit: rural depots, construction sites, remote operations and locations where fibre and mobile coverage are unavailable or impractical.
MPLS does not always need to disappear immediately. In some environments, MPLS remains useful during transition, for selected workloads, or until contracts expire. In others, the business is paying for a WAN model that no longer reflects how applications are used. The decision should be made site by site, not as a blanket policy.
Best fit: transition periods, specific workloads, contract-bound environments or sites where the risk case still justifies retained MPLS.
SD-WAN deployment succeeds or fails in the preparation phase.
The most common cause of missed deployment timelines is not the SD-WAN platform. It is underlay procurement starting too late. NBN and fibre installs in Australia can take 6 to 18 weeks in many zones. Procurement should start in parallel with assessment and design, not after the architecture is signed off.
The current environment is documented before any deployment path is recommended. This includes existing links, ISP arrangements, security policy, firewall position, application requirements, site-by-site connectivity, MPLS contracts, renewal dates, support responsibilities and known pain points. Application performance should be baselined across locations, especially for Microsoft 365, Microsoft Teams, SaaS, ERP, voice, video and hosted systems.
Underlay procurement starts in parallel with assessment. The multi-link design is completed per site: fibre, NBN Enterprise Ethernet, broadband, 4G/5G, Starlink and retained MPLS where required. ISP orders are placed early. Carrier lead times are mapped to rollout sequencing. SD-WAN hardware, licensing and management access are planned in parallel.
SD-WAN devices are configured against the design before they are shipped or installed. Application steering, failover thresholds, traffic classes, routing, firewall policy, segmentation, secure internet breakout and monitoring are configured and tested against the intended use of each site. Where zero-touch provisioning is used, devices should still be staged against a validated design. Zero-touch does not remove the need for architecture.
The first sites should be piloted before broader rollout. Pilot sites validate the design under real traffic: link failover, application steering, Microsoft 365 paths, firewall policy, security inspection, voice and video behaviour, user experience, monitoring, alerting and support workflows. Cutover should be scheduled, communicated and reversible. A rollback path should exist before every change window opens.
Larger deployments are staged by site, region, risk, business priority or application dependency. Each site should be validated under production load before legacy services are decommissioned. MPLS should not be terminated in the same change window as the first SD-WAN cutover unless there is a clear rollback path and a validated reason to do so. For larger rollouts, early sites can go live while later sites are still moving through procurement, staging or cutover planning.
The project is not finished when the devices are online. Ongoing operation should include link health monitoring, firmware management, application policy tuning, ISP escalation, WAN health reporting, lifecycle planning, change control and review. Deployment without operating ownership is where many SD-WAN environments drift.
SD-WAN can reduce MPLS dependence. Migration should be staged.
SD-WAN materially changes the commercial and operational model of a multi-site WAN. Traditional MPLS charges premium rates for guaranteed throughput on a single carrier-controlled network. SD-WAN can use multiple lower-cost underlays, steer traffic by application class, fail over between links and provide direct cloud breakout for Microsoft 365, Teams, SaaS and other cloud services. For many Australian organisations, the commercial case is significant — return on investment is usually realised within 12 to 18 months, driven primarily by MPLS cost displacement and reduced incident overhead. For the architecture decision that sits above the economics, see SD-WAN vs MPLS vs SASE.
- $500 to $2,000+ per site per month — fixed contract costs, annual escalation and 12 to 36 month lock-in
- 60 to 120 day provisioning for new sites — carrier-led timelines that make rapid expansion operationally difficult
- Cloud traffic backhauled through head office — 40 to 60 percent latency penalty added to Microsoft 365, Teams and SaaS at branch sites
- Single link per site, no failover — a carrier outage means complete site disruption until manually resolved
- Per-site management overhead — no centralised visibility; policy changes require manual intervention at each location
- 30 to 70 percent WAN cost reduction — broadband, NBN and 5G links aggregated intelligently at a fraction of MPLS per-megabit cost
- New sites deployed in days — zero-touch provisioning and pre-configured devices
- Direct cloud breakout at every site — Microsoft 365, Teams and SaaS traffic routed directly without backhauling
- Multi-link failover in seconds — primary fibre plus 4G/5G backup, automatic path switching before users notice
- Centralised management and reporting — visibility across every site, every link and every policy from one platform
For many Australian organisations, the commercial case is decisive. The cutover sequence is what protects it. MPLS may be removed where SD-WAN and alternative underlays provide the required performance and resilience; reduced where only some sites or workloads still justify it; retained temporarily while SD-WAN is validated; kept for specific workloads or contract-bound sites; or decommissioned site by site after production validation. The safer sequence is SD-WAN running in parallel with MPLS until each site is stable under production load, then MPLS decommissioned after validation.
The decision should be architectural before it is commercial. Otherwise the next carrier renewal starts designing the network.
The platform matters. The design and operating model matter more.
SD-WAN platforms differ in management model, security integration, branch architecture, licensing, reporting and fit with the existing environment. Fortinet, Cisco Meraki and VMware VeloCloud migration scenarios should be assessed against the organisation's actual requirements, not treated as interchangeable product options.
Fortinet can be a strong fit where the organisation already uses FortiGate firewalls, wants firewall and SD-WAN managed in one environment, or needs stronger alignment between routing, inspection, segmentation, VPN and branch security. FortiGate can combine next-generation firewall and SD-WAN capability in the same operating platform. That can reduce duplicated edge devices and simplify policy management. It also provides a direct path to FortiSASE without hardware replacement.
The fit still depends on site requirements, inspection load, licensing, existing firewall estate, internal capability, FortiManager or FortiAnalyzer requirements and managed operation after deployment.
Cisco Meraki can suit organisations that value cloud-managed simplicity, standardised branch deployment and a more centralised management experience. It may be a good fit for distributed environments where ease of management and consistent deployment are more important than deeper Fortinet-style security integration at the branch edge — the two platforms compare differently depending on the environment.
The decision should account for firewall requirements, reporting, security posture, licensing model, internal support capability and the broader network estate.
Some organisations will be reviewing VMware VeloCloud or existing SD-WAN arrangements as licensing, ownership, support or platform direction changes following the Broadcom acquisition. The migration decision should not be treated as a like-for-like replacement exercise. It should reassess underlay design, application policy, firewall integration, SASE readiness, cloud paths and operating ownership before selecting the next platform.
Vendor feature comparisons are useful, but they do not answer the operational question. The practical question is: who will design, deploy, monitor, tune, patch, document, escalate and improve the environment after go-live? A technically capable platform can still produce a weak operating outcome if ownership is unclear.
SD-WAN changes the security model at every branch.
SD-WAN often enables direct internet breakout from branch sites. That can improve Microsoft 365, Teams, SaaS and cloud performance by avoiding unnecessary backhaul through a central office or data centre. It also changes the security model. Every branch now needs clear policy around firewall inspection, web filtering, IPS, application control, VPN, segmentation, secure internet breakout, logging and incident response. If the network provider owns SD-WAN and a different provider owns security, incidents can fall into the gap between them. This is the split-vendor problem.
A branch performance issue may be a routing issue, a firewall inspection issue, an ISP issue, an application path issue or a policy issue. If no one owns the combined operating model, resolution slows down. The network provider says the network is working. The security provider says the firewall is clean. Neither is wrong. Neither is accountable. The organisation is left in the middle.
Integrated SD-WAN and firewall on a single platform eliminates this gap structurally. For Fortinet-based deployments, SD-WAN routing and NGFW run on the same hardware under the same operating system. When a link fails and traffic reroutes, security policy updates in the same process. There is no API boundary between the routing engine and the security engine.
Security integration should be designed from day one:
- Firewall policy aligned to SD-WAN traffic paths
- Secure internet breakout defined per site and user group
- Segmentation planned before cutover
- IPS and application control tuned to avoid noise
- VPN and remote access reviewed against the new model
- SASE and ZTNA readiness considered where remote access or cloud security needs to evolve
- Logging and escalation ownership defined before go-live
SD-WAN should make the network easier to operate, not create a new split between connectivity and security.
Most SD-WAN deployment failures are operational, not technical.
The technology is mature. The common failure modes sit around preparation, sequencing and ownership.
The deployment starts from a spreadsheet of sites rather than a real understanding of each location. Existing links, carrier contracts, firewall policy, local dependencies, application use, 4G/5G coverage, business hours, critical users and site-specific risks are not documented properly.
The site audit is not administration. It is the input that determines underlay selection, hardware sizing, rollout sequencing and rollback planning.
NBN and business fibre installs can take 6 to 18 weeks in many Australian zones. If ISP orders are placed only after architecture sign-off, underlay becomes the project bottleneck. This is the single most common cause of missed SD-WAN deployment timelines.
Underlay procurement belongs in week one alongside design.
SD-WAN should route traffic based on application requirements, link quality and policy. Microsoft 365, Teams, ERP, file replication, SaaS, voice, video and operational systems have different latency, reliability and inspection requirements. A single generic policy template applied across every site loses much of the value of SD-WAN. Misconfigured SD-WAN policy can route latency-sensitive applications over the wrong path, trigger failover on healthy links or create routing instability.
Per-application-class design and application-specific testing before cutover are not optional.
The highest-risk cutover pattern is SD-WAN go-live and MPLS termination in the same change window. If performance regresses or a fault appears under real traffic, there is no clean rollback path.
The safer sequence is SD-WAN running in parallel with MPLS until each site is stable under production load, then MPLS decommissioned site by site after validation.
SD-WAN is treated as a project rather than an operating commitment. The environment goes live, but ownership for policy, firmware, monitoring, ISP escalation, reporting and incident response is not clearly defined. Policy drift, firmware gaps and carrier issues do not manage themselves.
The operating model decision belongs in the deployment scope, not after it.
SD-WAN deployment is an operating discipline before it is a platform rollout.
The hardware is straightforward. The outcome depends on underlay timing, site sequencing, rollback planning, security integration and managed operation being defined before the rollout starts.
For Australian multi-site organisations with MPLS contracts approaching renewal and a cloud-first application footprint, SD-WAN is usually a serious architecture conversation. The commercial case can be strong. The deployment path is well proven. The technology is not the uncertain part. The operational questions determine whether the investment delivers — who designs it, who deploys it, who owns it after go-live, who manages the carriers, who tunes policy when application requirements change, who responds when an incident crosses network and security domains, who reports on WAN health and ongoing improvement.
A carrier product without engineering depth can produce a WAN without security integration. A vendor-direct model without internal SD-WAN capability can produce a platform that is deployed but never properly operated. The provider model decision matters as much as the platform decision.
The technology is not the uncertain part. The failure mode is choosing a provider model that does not match the organisation's internal capability.
If your MPLS renewal date is closer than your longest underlay lead time, the carrier is already designing your next WAN — a structured review puts the architecture decision back with you.
Review the WAN before renewal →Where Inlight IT works alongside the team:
Existing links, ISP arrangements, application requirements, MPLS contract position and renewal dates are documented before anything is recommended — with Microsoft 365, Teams, SaaS and application performance baselined across locations.
NBN Enterprise Ethernet, business fibre, 4G/5G and Starlink are sourced across providers per site rather than forced into a single carrier bundle.
SD-WAN, firewall policy, secure internet breakout, segmentation and branch security are designed as one operating environment — with platform fit assessed across Fortinet, Cisco Meraki or VMware VeloCloud migration where applicable.
SD-WAN runs in parallel with MPLS where required until each site is stable under production load. Legacy services are decommissioned site by site after validation, with the pilot approach and validation plan defined up front.
Link health monitoring, firmware management, policy tuning, ISP escalation and WAN health reporting sit with one accountable team.
SD-WAN delivered across a national branch network.
Beijer Ref — refrigeration, HVAC and climate technology · national multi-site SD-WAN.
Beijer Ref operates a national branch and commercial site environment across Australia. The network needed to support reliable site connectivity, centralised visibility, standardised policy and a more supportable operating model across more than 110 locations.
Inlight IT delivered a staged SD-WAN rollout across the environment, replacing fragmented site-by-site connectivity with a single managed network across every state. The architecture was sequenced for staged cutover, validated change, centralised policy and managed operation after go-live.
The important point was not only the number of locations. It was the discipline around the rollout: architecture before deployment, staged cutover, validated change, centralised policy and managed operation after go-live. Read the Beijer Ref SD-WAN case study.
Questions that come up before an SD-WAN deployment.
Is SD-WAN better than MPLS for Australian organisations?
What is the most important factor when evaluating an SD-WAN provider?
How long does an SD-WAN deployment take?
What are the main SD-WAN deployment risks?
Will migrating from MPLS to SD-WAN cause downtime?
How much does managed SD-WAN cost?
What does the ongoing managed service include after deployment?
Is SD-WAN being replaced by SASE?
Decide the architecture before the carrier decides it for you.
A practical conversation about SD-WAN design, underlays, MPLS transition, firewall integration and managed operation.
Discuss Managed SD-WAN