7 min read · Published August 24, 2026 · Vast Networks
Tier the sites before pricing anything
Sites are rarely equivalent, and treating them as though they are is the most expensive mistake in multi-site connectivity. Classify each by what actually happens when its connection degrades. A distribution center that cannot scan or ship is one tier. A branch office where people can work around it for an afternoon is another. A remote yard with two cameras is a third.
That classification determines the underlay. Tier one sites justify dedicated, committed, symmetric capacity, because the cost of the outage exceeds the cost of the circuit. Tier three sites frequently do not, and buying dedicated circuits there is money that would deliver more value elsewhere in the estate — often funding genuine redundancy at the sites that need it.
Site-to-site traffic is a different product
Once each site can reach the internet, the second question is what travels between them: replication, imaging, file shares, backup to a central target, voice between offices, control and telemetry. Most organizations start by tunnelling that across their internet connections, and it works until it does not.
The reason it stops working is structural rather than accidental. A VPN inherits the behaviour of the paths underneath it — latency that varies with routing, jitter that varies with congestion at both ends, and encryption overhead on hardware sized for something else. Symptoms are recognizable: transfers that used to finish and now do not, an application that is fine in the morning and sluggish mid-afternoon, inter-site calls that degrade while external calls stay clear.
Where the inter-site traffic is genuinely important, point-to-point transport takes it off the public internet entirely. It is not a replacement for internet access at each site; it is a separate path for the traffic that should not be competing with anything.
When an overlay earns its place
Beyond roughly a dozen sites, managing each connection individually becomes its own problem, and that is where SD-WAN starts to pay. It steers traffic per application across whatever paths exist, fails over in under a second, and applies consistent policy across the estate without configuring each site by hand.
What it does not do is create capacity or reduce jitter on the path it selects. An overlay deployed to compensate for inadequate circuits — particularly if the business case funds it by downgrading those circuits — tends to disappoint at exactly the sites that mattered. The design that works is layered: correct underlay per tier, private transport where inter-site traffic justifies it, and an overlay across the top if the estate is large enough to need one.
Practical design patterns
**Hub and spoke.** A dedicated circuit at the main site, point-to-point transport out to the sites that exchange significant traffic with it, and commodity access elsewhere. Simple, and correct for most organizations where one location is genuinely central.
**Paired sites.** Two locations exchanging the bulk of the traffic — a plant and a head office, a campus and a data center — connected directly, with everything else on internet access. Minimal moving parts.
**Tiered estate with an overlay.** Many sites, mixed requirements, central policy, and automatic failover. Appropriate at scale, and over-engineered below it.
Whichever pattern fits, map the real traffic flows before committing. The assumed pattern and the measured one differ often enough that the exercise usually changes at least one decision.
What to check per site before you buy
Availability is address-level, not city-level. Distance from existing fiber, the route in, land ownership, permitting, and building entry decide both cost and timeline at each location, and they vary between buildings that look equally accessible. For a multi-site project this matters twice over, because the site that is hardest to reach usually sets the schedule for the whole rollout.
Sequence accordingly. Where one location requires construction and the others do not, there is rarely a reason to hold the easy sites hostage to the difficult one — stage the deployment and let the hard site follow its own permitting timeline.