SD-WAN vs MPLS: Connecting Provincial Branches to Head Office

The Pakse branch calls at 10 am: "The system is crawling, we can't print invoices." The IT team in Vientiane checks the VPN. The branch's internet line is up, but with 8% packet loss. There's no second line, so there's nothing to do except call the ISP and wait.

This is a familiar story for organizations headquartered in Vientiane with branches in Luang Prabang, Savannakhet, Pakse and other provinces: banks, insurers, retailers, logistics firms. Branches need dependable access to central ERP, core banking or POS, but internet quality varies a lot by province, and some towns have only one fiber provider to choose from.

There are three main options.

MPLS: the carrier's private road

MPLS is a private WAN service built and run by a telecom carrier. Traffic stays on the carrier's network instead of the public internet, usually with contractual SLAs for latency and uptime.

Its strengths are predictable performance and end-to-end QoS. Its weaknesses are more numerous than people expect: high cost per Mbps, weeks or months to provision a new branch, lock-in to one carrier, no encryption by default, and traffic to Microsoft 365 or other SaaS has to hairpin through head office before it reaches the internet.

Traditional IPsec VPN: cheap, but blind

The branch firewall builds an encrypted tunnel to head office over an ordinary internet line. It's inexpensive, and most organizations in Laos start here. The problem is that the tunnel doesn't know when the line is degrading. As long as the link is up, it keeps sending traffic, even when packet loss is bad enough to make applications unusable. Failover to a second line is possible, but slow and fiddly to configure.

SD-WAN: smarter about which path to use

SD-WAN is a software overlay running across several kinds of transport (fiber internet, 4G/5G, or existing MPLS). It builds encrypted tunnels between sites, continuously measures latency, jitter and packet loss on every path, and sends each application over whichever path is best at that moment.

In the Pakse example, SD-WAN would see the packet loss and move POS traffic onto the 4G link within seconds, without anyone touching anything.

What you gain: several cheap internet links used at once, every branch managed from one dashboard, zero-touch provisioning (ship the box to the branch, plug it in, and it pulls its own configuration), and local breakout so Microsoft 365 goes straight out from the branch.

What you accept: quality still depends on local internet (SD-WAN can pick the best road but can't build a better one), there are annual licence fees, and branch security has to be designed properly because every branch now has its own internet exit.

Side by side

Platforms you are likely to be quoted in 2026

The brand matters less than three things: whether your team can run it from Vientiane, how licensing behaves when it expires, and whether spares and RMA come through Thailand in days or weeks.

Ask every SD-WAN vendor the same questions

• How many seconds does failover take, and do VoIP calls in progress survive it?
• Is 4G/5G built in, or is a separate modem needed?
• Are firewall and IPS included, or extra?
• Is the controller/orchestrator cloud-hosted or self-hosted? If it becomes unreachable, do branches keep working?
• How is licensing priced (per device, per bandwidth tier), and what does the appliance do if a licence lapses?
• Does it produce link-quality reports you can take to your ISP?

That last one is more useful than it sounds. With 30 days of packet-loss graphs in hand, conversations with the ISP get a lot shorter.

The answers let you compare quotations from different brands on equal terms, rather than on headline throughput figures that rarely reflect a branch's real traffic.

Migrating without taking branches offline

1. Inventory applications and traffic at each branch: what's used, how much, and when
2. Find out which ISPs serve each province. Pick two different providers, or fiber plus 4G/5G
3. Choose a topology: hub-and-spoke to the data center, or full mesh if branches talk to each other a lot
4. Write application policies: core banking/ERP on the best path; video and general browsing broken out locally
5. Pilot one or two branches in parallel with the existing circuits for at least a few weeks, long enough to see a storm or a power cut
6. Roll out the remaining branches in phases, then reduce or retire MPLS

Worked example: two links for a 15-person branch

Rough peak demand for a branch with POS, ERP, Microsoft 365 and a few cameras:

A 50 Mbps fiber line covers this with room to spare. The 4G/5G line only has to carry about 5 Mbps of business traffic, which matters if it is a data-capped package. That is exactly what application policies are for: on a failover day, invoices keep printing and YouTube waits. Check the upload speed of the fiber line too. Many packages in Laos are asymmetric, and camera viewing and cloud backup both use upload.

What stops SD-WAN from delivering

First and most common: two "different" links that actually follow the same fiber route or climb the same pole. One truck snags the cable and both go down. Ask the providers about routing, and go and look at the poles yourself.

Others: local breakout without a firewall at the branch, no application policies (which turns SD-WAN into an expensive VPN), and forgetting annual licences in the TCO.

Our view

For most organizations in Laos we recommend SD-WAN integrated with a next-generation firewall in a single appliance per branch, with fiber from one ISP and 4G/5G from another. One box is easier to manage, and you only need one type of spare.

Banks and organizations whose core systems simply can't stop: keep a private circuit as the primary path and let SD-WAN manage both (hybrid). You keep the MPLS SLA and gain SD-WAN's intelligence.

Every branch needs a UPS. Power cuts in the provinces are routine, and the best failover design is useless if the SD-WAN appliance itself goes dark. Finally, choose a platform your Vientiane IT team can run without driving to the provinces.

Start with your branch list

Send us your list of branches, each one's current ISP and speed, and the systems they rely on. We'll tell you which branches need a second line first and sketch a topology. If you're not sure how much bandwidth each branch actually needs, try our bandwidth calculator.