MPLS exit is the first decision. SD-WAN is the replacement. SASE is the next step.
Most organisations comparing SD-WAN, MPLS and SASE are not choosing between three interchangeable WAN options. They are usually at one of two points: an MPLS renewal decision — renew the carrier-managed private network, or exit to SD-WAN over broadband, NBN, business fibre, 4G/5G or Starlink — or a post-SD-WAN decision about extending the foundation with cloud-delivered security through SASE. Those are different decisions. The common mistake is treating MPLS, SD-WAN and SASE as three competing options at the same decision point. For most Australian multi-site organisations, the practical sequence is simpler: MPLS exit first. SD-WAN deployment second. SASE extension third. Not all at once.
See the decision sequenceThe MPLS renewal or exit decision; SD-WAN as the replacement layer; SASE as the next-step security architecture; cost, performance and security differences; Australian underlay constraints; MPLS contract timing and notification windows; migration sequence and pilot validation; and when MPLS still fits. Written for Australian multi-site organisations approaching a WAN architecture decision.
The right answer depends on where the network sits today.
The variables that decide the comparison:
- Application and cloud architecture — Microsoft 365, SaaS, Azure and cloud workloads usually favour SD-WAN with direct cloud breakout.
- Site count and topology — multi-site environments need site-by-site underlay design, carrier diversity and centralised operation.
- Current WAN contract status — MPLS renewal windows, early termination clauses and rollover terms shape the migration sequence.
- Connectivity availability by site — NBN, business fibre, broadband, 4G/5G, Starlink and retained MPLS need to be assessed per location.
- Security and compliance posture — SASE becomes relevant when branch, remote user and cloud security policy need to converge.
- Operational capability after deployment — SD-WAN and SASE need active management, not only carrier provisioning.
MPLS, SD-WAN and SASE sit at different stages of the WAN evolution.
The comparison is often framed as SD-WAN vs MPLS vs SASE, but that framing creates confusion. MPLS, SD-WAN and SASE are not three equal options for the same architecture decision. They represent different stages of the network operating model.
This is the renewal or exit decision. The question is whether to renew MPLS at the next contract point or replace the MPLS WAN with SD-WAN over broadband, NBN, business fibre, 4G/5G, Starlink or mixed underlay. For most Australian multi-site organisations, the commercial and architectural case for SD-WAN is strong.
MPLS costs significantly more for equivalent bandwidth, integrates poorly with cloud applications, and its guaranteed QoS advantage is meaningful only for specific latency-critical workloads that can usually be identified in advance.
This is a later extension decision. SASE is not an alternative to SD-WAN. It builds on SD-WAN by adding cloud-delivered security under a common policy model. If SD-WAN is not yet deployed or designed, SASE is usually not the immediate project.
An organisation evaluating SASE has usually already deployed SD-WAN, committed to SD-WAN, or accepted that the old MPLS-centric model is no longer the right foundation.
For most environments, the clean sequence is:
Timed against renewal windows, notice periods and early termination clauses.
Designed per site, not templated per carrier.
Validated under production load before anything else changes.
When branch, remote access and cloud security requirements have matured.
Different eras of WAN architecture.
MPLS, SD-WAN and SASE come from different eras of WAN architecture, and each makes different assumptions about traffic, trust and control.
MPLS is a carrier-managed private WAN using dedicated circuits with guaranteed quality of service. It is expensive and inflexible, but it remains the most consistent option for specific latency-sensitive traffic. MPLS is appropriate where guaranteed QoS is genuinely required, where broadband options are poor, or where dedicated carrier infrastructure is a contractual, operational or regulatory requirement. It is being displaced as the primary WAN model, but it is not technically obsolete.
The trade-off is clear: the carrier controls the network, performance is predictable, the cost is high, and flexibility is low.
SD-WAN is a software intelligence layer that runs over commodity connectivity: broadband, NBN, business fibre, 4G/5G, Starlink and, where required, retained MPLS. It prioritises applications, fails over automatically, supports direct cloud breakout and reduces dependency on expensive private circuits. For Microsoft 365, Azure, Teams and SaaS-heavy environments, SD-WAN usually fits the current application model better than MPLS — the shift away from traditional WAN architecture is as much about security as connectivity.
The trade-off is that SD-WAN runs over best-effort internet underlay. It improves path selection and resilience, but it cannot guarantee the deterministic latency of MPLS.
SASE, or Secure Access Service Edge, combines SD-WAN with cloud-delivered security under a single policy framework. It adds Secure Web Gateway, CASB, ZTNA and Firewall as a Service to the network architecture. SASE does not replace SD-WAN. It extends SD-WAN.
The value is consistent security policy across branches, remote users and cloud applications, with traffic inspected and controlled closer to the user and application rather than forced back through a central firewall.
Where each model wins, and where the answer is more nuanced.
Compare the three models across the same dimensions: primary role, cost model, performance, security, cloud fit, flexibility and operating model.
- Cost model — high circuit cost, carrier-managed, long contract terms
- Performance — predictable latency and QoS for private paths
- Security — network isolation, but no native encryption or threat inspection
- Cloud fit — poor when traffic is backhauled through a hub
- Flexibility — low; new sites and bandwidth changes can take weeks or months
- Operating model — carrier-managed network with limited customer control
- Cost model — lower underlay cost, more carrier flexibility, platform and managed service cost added
- Performance — strong for cloud and SaaS; direct breakout removes backhaul; variable underlay must be managed
- Security — IPsec encryption, branch firewall integration and application-aware routing where configured
- Cloud fit — good; direct cloud breakout from each branch
- Flexibility — high; new sites can be deployed faster once underlay is available
- Operating model — customer or MSP-managed platform requiring active policy, firmware and link management
- Cost model — SD-WAN cost plus security platform cost; replaces or consolidates some separate security services
- Performance — strong where cloud-edge inspection is close to users and applications; dependent on SASE platform and PoP design
- Security — SWG, CASB, ZTNA and FWaaS with consistent policy across users and branches
- Cloud fit — strong; cloud-edge inspection without forcing traffic through a central firewall
- Flexibility — high; policy changes can apply across users, branches and cloud services
- Operating model — identity, access, branch networking and cloud security operated as one policy model
An honest comparison acknowledges that MPLS still has genuine advantages in specific scenarios. The mistake is treating the decision as purely technical. It is also a commercial decision, a timing decision and an operating-model decision. SD-WAN delivers most of the MPLS benefit at a fraction of the cost for most workloads. The exception is latency-critical applications that require guaranteed, not best-effort, performance. Those organisations usually know who they are.
The right architecture depends on workload, timing and operating capability.
- Latency-critical applications require guaranteed QoS
- Voice, video production, real-time trading, industrial systems or specialised workloads depend on deterministic performance
- Locations do not have reliable broadband, NBN, fibre, 4G/5G or Starlink as a viable underlay
- Current MPLS contracts have significant penalty clauses that make early exit unjustifiable
- The existing MPLS network has no material performance or cost problem
- A regulatory, contractual or operational requirement demands dedicated carrier infrastructure
- A small MPLS footprint is retained for specific workloads while SD-WAN carries the majority of sites
MPLS is not obsolete. It is increasingly narrow in fit.
- Microsoft 365, Azure or SaaS are primary applications
- MPLS backhaul is adding latency to cloud application performance
- The organisation has five or more sites and MPLS circuit costs are a significant line item
- MPLS contracts are approaching renewal and the renewal cost is not justified
- New sites need to be added faster than MPLS provisioning allows
- 4G/5G failover or multi-path redundancy is needed without the MPLS cost model
- Branch connectivity and security need central management rather than site-by-site exceptions
- The business wants more carrier flexibility across sites
- SD-WAN is deployed or committed
- Security policy needs to be consistent across branches and remote users
- Branch security is inconsistent and separate products per site are creating overhead
- Remote users need the same policy enforcement as branch users
- Hybrid work means traffic leaves the network without a consistent inspection point
- Contractor and third-party access needs application scoping rather than broad VPN access
- SaaS and AI tool usage requires visibility, policy and audit evidence beyond the current WAN
- Identity, remote access and cloud security readiness are mature enough to support the SASE transition
SASE is powerful, but it should not be used to avoid doing the WAN design properly.
The right time to exit MPLS is before the renewal, not at it.
Most MPLS to SD-WAN migrations are triggered by contract renewal. That is the right moment to exit, but the preparation needs to start earlier. For Australian multi-site organisations, the practical planning window is usually 6 to 12 months before MPLS renewal.
The practical sequence for MPLS exit:
MPLS exit is usually overdue when:
- MPLS circuit cost is disproportionate to the bandwidth delivered compared with broadband alternatives at the same sites
- Cloud application performance for remote offices is degraded by MPLS backhaul to a central breakout point
- New sites are being added without MPLS because the provisioning lead time is too long
- The organisation is paying for symmetric MPLS bandwidth it no longer needs because traffic has shifted to SaaS
- MPLS renewal is approaching and the business case has not been evaluated against current SD-WAN alternatives
MPLS decommission is the final step, not the first.
MPLS exit should be staged, controlled and validated.
MPLS exit should not be disruptive. The strongest migration approach is practical and controlled: assess, design, deploy in parallel, validate and then decommission. The SD-WAN deployment guide covers the full rollout discipline in depth.
Current WAN topology, MPLS circuits, contract expiry dates, early termination clauses, carrier arrangements, underlay options and application requirements are documented before platform selection. This is where the project risk is usually found.
Each site is assessed for available connectivity: NBN, business fibre, broadband, 4G/5G, Starlink and retained MPLS where needed. At least two independent paths per site are preferred, with carrier and physical-path diversity where available.
The SD-WAN architecture is designed before hardware is deployed. That includes hardware sizing, application-aware policy, failover design, centralised management, security inspection and reporting. The design should reflect the application mix, not a generic template.
SD-WAN is deployed in parallel with MPLS at the pilot site. Application performance, failover, Microsoft 365, Teams and SaaS behaviour are validated before broader rollout. This step confirms the design under production load.
Sites migrate progressively. MPLS remains until SD-WAN is stable under production load at each site. Contract expiry and decommission timing should be aligned to avoid unnecessary overlap and early termination penalties.
The underlay design needs to reflect Australian site reality.
Australian WAN design has local constraints that generic SD-WAN guidance often misses.
Metropolitan sites often have reliable FTTP, HFC or business fibre suitable for SD-WAN underlay. Regional and remote sites may rely on FTTN, Fixed Wireless, satellite, 4G/5G or Starlink.
Connectivity assessment per site is mandatory before SD-WAN design. A site that cannot support reliable internet underlay may need to retain MPLS temporarily or use a mixed underlay model.
Australian regions for Microsoft Azure and Microsoft 365 are concentrated around Sydney and Melbourne. For sites outside those states, direct cloud breakout from branch sites is usually faster and more reliable than backhauling traffic through a Sydney or Melbourne hub.
Round-trip latency from Perth, Darwin or regional locations still matters for real-time applications, so path testing should be part of design.
The Australian MPLS market has historically reflected carrier-managed private-network economics rather than commodity connectivity economics. SD-WAN over broadband, NBN, business fibre and wireless can often deliver a 60 to 80 percent cost reduction at equivalent or better performance for standard workloads.
That reduction is real, but it should not be the only decision criterion. The operating model changes as well. More underlay links, more policy decisions and more dependency on internet path quality need to be actively managed.
Site-by-site assessment comes before platform selection.
These are the specific items to review at each site before SD-WAN design, platform selection or carrier negotiation.
- NBN connection type and speed at each site: FTTP, HFC, FTTN, Fixed Wireless or satellite
- Business fibre or direct fibre options for head office, data-centre-connected sites and high-throughput locations
- 4G/5G or Starlink suitability for failover, remote sites, temporary sites or locations without viable fixed-line options
- Current MPLS circuit bandwidth and cost per site as the commercial baseline
- MPLS contract expiry dates, renewal windows and early termination clauses
- Application mix per site, including Microsoft 365, Teams, SaaS, ERP, file replication and latency-sensitive workloads
- Carrier options available at each site and whether two independent paths can be achieved
- Current firewall and security model, including whether local breakout can be secured properly
Platform selection should follow this assessment, not lead it — including the choice between platforms such as Fortinet SD-WAN and Cisco Meraki.
MPLS exit timed to the renewal.
A 12-site Australian property services organisation was running Telstra MPLS across all sites, with MPLS renewal approaching and a 30 percent cost increase flagged by the carrier. SD-WAN design was scoped before the renewal deadline. Sites were validated under production load before MPLS was decommissioned at each location.
Figures from the engagement described above. The outcome was not simply cheaper connectivity. It was a controlled migration from a carrier-managed MPLS network to an SD-WAN operating model, timed around the commercial renewal point and validated site by site.
The question now is timing and sequencing.
For most Australian multi-site organisations, the MPLS vs SD-WAN decision was settled by the commercial case years ago. The question now is timing and sequencing, not whether SD-WAN is the right direction. SD-WAN replaces MPLS at the next renewal point when the technical work has been front-loaded into assessment, design and underlay planning. The cutover is operationally uneventful when the environment has been validated properly.
- Plan the exit 6 to 12 months before MPLS renewal, not at it — missing the notification window can convert a planned migration into a forced renewal.
- Site-by-site connectivity assessment determines the architecture — platform choice comes after the assessment, not before it.
- Migrate progressively — MPLS decommission is the last step, not the first. The new environment should run in parallel until SD-WAN is validated at every site.
- Treat SASE as the next decision, not a parallel one — address SD-WAN first, then extend with cloud security when SD-WAN is operational.
- Cost reduces, but the operating model changes — more links, more security policy decisions per site and more dependency on internet underlay quality need to be managed.
- Do not treat MPLS exit as a pure cost project — SD-WAN without properly configured application-aware routing, tested failover and a clear operating model is not an improvement over MPLS. It is a cheaper way to create a different set of problems.
Commercial flexibility is the benefit. Consistent application performance under variable internet quality is the trade-off.
If your MPLS renewal notice window falls inside the next 12 months and no site-by-site underlay assessment exists yet, the migration is already running on the carrier's timeline rather than yours.
Start with a network review →Where Inlight IT works alongside the team — SD-WAN designed for the environment, not templated from a vendor playbook. The right engagement starts by understanding current WAN architecture, MPLS contract position, site-by-site connectivity, application requirements, security architecture and who will operate the environment after go-live:
Circuit inventory, carrier contracts, renewal windows, notice periods, early termination risk and current spend.
NBN, business fibre, broadband, 4G/5G, Starlink and MPLS retention where needed.
FortiGate sizing, FortiManager architecture, underlay strategy, application-aware routing, failover and security inspection for local breakout.
Pilot site, parallel operation, validation, rollback and site-by-site decommission aligned to contracts, with an indicative deployment timeline.
Whether SASE is relevant now, later or not yet, based on SD-WAN maturity, identity, remote access and security requirements.
Link health monitoring, firmware management, policy tuning, carrier escalation and WAN reporting.
Decision-stage questions Australian organisations ask before changing WAN architecture.
Is SD-WAN more secure than MPLS?
Is MPLS being replaced by SD-WAN?
Why is MPLS so expensive compared to SD-WAN?
Does SD-WAN replace MPLS entirely?
Where does SASE fit in this comparison?
How long does MPLS to SD-WAN migration take?
What connectivity does SD-WAN require at each site?
Can SD-WAN guarantee the same performance as MPLS?
Can MPLS and SD-WAN run together?
Should we plan SASE at the same time as SD-WAN?
Review the WAN architecture before committing to the platform path.
An engineer-led assessment of MPLS contract position, site-by-site underlay and migration sequence — before hardware, licensing or carrier decisions.
Book an SD-WAN Review