Networking & Connectivity
Why your SaaS feels slow at the branch office
Headquarters says the application is fine. The branch says it is unusable. Both are right, and the reason is usually the path the traffic takes, not the application.
A WAN built for a different decade
Many enterprise WANs were designed when the applications lived in the data centre. Branches connected to headquarters over MPLS, and all internet traffic left through one central gateway where it could be inspected. It was simple, secure and made sense.
Today the applications that branches use most, including email, collaboration, CRM and ERP, are delivered from SaaS and public cloud. The traffic still follows the old path: out of the branch, across the WAN to headquarters, through the central firewall and proxy, then out to the internet. Then all the way back.
The applications moved to the cloud. The traffic is still taking the long way round.
Four hidden causes of branch slowness
- Backhaul distanceEvery round trip through headquarters adds latency. Interactive applications such as calls, meetings and editing documents together make many round trips, so the delay compounds.
- DNS in the wrong placeSaaS providers route users to the nearest entry point based on where DNS is resolved. If a branch resolves names at headquarters, it may be sent to a front door far from where the user actually is.
- Central inspection bottlenecksProxies and TLS inspection that were sized for yesterday’s traffic become a queue. Some SaaS providers, Microsoft 365 among them, advise against inspecting their latency-sensitive traffic at all.
- One path, no choiceA single circuit cannot route around congestion or loss. When it degrades, every application degrades with it.
What SD-WAN changes
SD-WAN builds an overlay across whatever links a site has, such as MPLS, broadband or 4G and 5G, and chooses the best path for each application in real time. Crucially, it allows local internet breakout: trusted SaaS traffic can leave the branch directly, while other traffic still goes to the data centre.
With local breakout and local DNS resolution, branch users reach the nearest SaaS entry point over the shortest path. Link quality is measured continuously, so a failing circuit is avoided before users notice.
Where SASE comes in
Local breakout raises a fair question: if traffic no longer passes the central firewall, where is it inspected? SASE (secure access service edge) answers that by delivering security from the cloud: secure web gateway, cloud access security broker, Zero Trust network access and firewall as a service, enforced close to the user wherever they are.
Think of it as two halves. SD-WAN fixes the path. SASE moves security onto that path. Many organisations adopt SD-WAN first, where most traffic still goes to their data centres, then add cloud-delivered security as SaaS and remote work grow.
Before you change anything, measure
- Split each site’s traffic by destination: data centre, SaaS, public cloud and general internet.
- Test latency from branches to the SaaS services people use most, from the branch and via headquarters.
- Check where each site resolves DNS, and which SaaS entry points it is being sent to.
- List every site’s circuits, contract end dates and criticality. Contract dates often set the migration order.
- Check how close a cloud security provider’s points of presence are to your sites, especially across India, the Middle East, Africa and Asia-Pacific.
