How to network multiple office locations for a small business

The first office was easy. One internet connection, one firewall, one switch, one Wi-Fi network, one DHCP scope, one set of file shares. Then the business opened a second location and the questions started: how do people at the new office reach the file server at the main office, what does it cost to connect them, do we need our own equipment at the second site, and what happens when one of the two connections goes down. The fourth or fifth office turns those questions into a design problem.

Multi-site networking is one of the topics where SMB advice is either enterprise-grade overkill or a hand-wave to “just use VPNs.” The truth sits in the middle. There are four real ways to connect offices at small business scale, each with its own cost, complexity, and right-fit scenarios. There is also a real architectural choice underneath the connectivity question – whether to put shared resources in the cloud and treat each office as a thin endpoint, or to keep them on-premises and federate the sites with site-to-site links. Both work. They cost different amounts and need different operational depth.

This article covers how to think about multi-site network design at SMB scale, the four real connection options (site-to-site VPN, SD-WAN, MPLS, dedicated point-to-point) with honest cost and use-case framing, how shared resources actually move between sites in 2026, what changes at 2, 3, 5, and 10 locations, the cost math per added site, the operational mistakes that take down a multi-site network, and when handing it to a managed network provider stops being optional. It is written for owners, office managers, and IT generalists planning a second-location opening, an existing multi-site network refresh, or an acquisition that suddenly added three new offices.

Short answer: how do you connect multiple offices

The honest answer for almost every small business in 2026 is: put the shared resources in the cloud (Microsoft 365, SharePoint, OneDrive, cloud-hosted line-of-business apps), give every office a business firewall with dual-WAN failover, and connect the sites with site-to-site VPN tunnels for the few resources that genuinely need to stay on-premises. Total cost runs $200 to $600 per location per month including connectivity. Add SD-WAN if you have three or more locations with real-time traffic that cannot tolerate failover blips, or if managing per-site firewall policies becomes a tax on the IT generalist.

The older multi-site pattern – file servers and Active Directory at headquarters, branch offices reaching back over MPLS or site-to-site VPN to use them – still exists but is shrinking. Cloud-first multi-site networks are simpler, cheaper, and more resilient than the on-premises-federated alternative for the vast majority of SMBs.

Multi-site networking at a glance

Connection option	What it does	Typical cost per site	Best for
Site-to-site VPN	Encrypted tunnel between two firewalls over commodity internet	$0 incremental (firewall already has it)	2-3 sites, modest cross-site traffic, cloud-first business
SD-WAN	Multiple WAN links per site, app-aware routing, central management	$200-$500/mo per site	3+ sites, real-time traffic, centralized policy
MPLS	Dedicated private circuit between sites	$500-$2,000/mo per circuit	Rarely the right answer at SMB scale
Point-to-point fiber	Dedicated dark fiber or wavelength between sites	$1,000-$5,000/mo per link	Same-city campuses, edge cases

The realistic SMB stack is “site-to-site VPN for small multi-site networks, SD-WAN once you cross 3-5 locations.” MPLS and dedicated fiber show up in conversations but rarely fit the SMB budget or use case.

The architectural choice that comes before connectivity

Before picking how to connect offices, the bigger decision is where shared resources actually live. This sets the bandwidth requirements between sites, the failure modes when a link goes down, and the cost of each option.

Cloud-first multi-site

Shared file storage in SharePoint and OneDrive. Email and collaboration in Microsoft 365 or Google Workspace. Line-of-business applications in SaaS or self-hosted in Azure, AWS, or Google Cloud. Identity in Entra ID (formerly Azure AD) or Google identity. Each office connects to the internet locally and reaches the cloud directly. Sites communicate via the cloud, not by sending traffic back and forth between offices.

This is the model most SMBs should be running in 2026. Each office becomes a self-contained pod that needs three things: a working internet connection, a properly configured business firewall, and Wi-Fi. The site-to-site connection between offices becomes secondary – useful for the few resources that have not yet moved to the cloud, not the primary path for daily work.

Strengths: each site is independent, so one site’s network failure does not affect another site’s work. Bandwidth scales by adding internet at each location, not by upgrading expensive inter-site links. The IT team manages identity and applications centrally without owning servers at every location.

Weaknesses: ongoing cloud licensing cost is real. A 50-person business across three locations might spend $1,500 to $4,000 per month on Microsoft 365 plus cloud-hosted applications. Internet quality at every location matters more because every workload depends on it.

On-premises with site-to-site federation

File servers, Active Directory, line-of-business applications, and shared printers live at headquarters (or a primary data center). Branch offices connect over site-to-site VPN, SD-WAN, or MPLS to reach those resources. Each branch may have local domain controllers, print servers, and caching for performance, but the authoritative copies live at the primary site.

This was the standard SMB multi-site model from roughly 2000 to 2015. It still exists in industries where on-premises is required (some healthcare, manufacturing with industrial control systems, businesses with very large local datasets), or where the cost of migrating off has not been justified yet.

Strengths: data stays under the business’s physical control. Once built, the ongoing cost is mostly the inter-site links and hardware refresh. Predictable and well-understood operational pattern.

Weaknesses: every site depends on the central site being reachable. When the headquarters internet goes down or the site-to-site link drops, branches lose access to file servers and authentication. Bandwidth between sites becomes a recurring cost and a recurring complaint. Refreshing hardware at the headquarters site is a multi-site event.

Hybrid – the realistic state of most SMBs today

Most SMBs run a hybrid. Email is in Microsoft 365. Some files have moved to SharePoint, others are still on the on-prem file server. The line-of-business app is still on a server in the closet at headquarters. Identity is partially in Entra ID, partially still on local Active Directory. Branch offices reach into headquarters for the on-prem-only pieces and reach the cloud directly for everything else.

The right multi-site network design depends on which side of the hybrid the business is moving toward. A business actively migrating to the cloud should not invest heavily in MPLS or high-bandwidth inter-site links – the workload they were sized for will be gone in 12-24 months. A business that has decided to stay hybrid for the foreseeable future should pick the inter-site option that fits the bandwidth and reliability needs of the on-prem workload.

The four real ways to connect offices at SMB scale

1. Site-to-site VPN over commodity internet

The cheapest and most common starting point. Each office has a business firewall (Meraki, Fortinet, SonicWall, WatchGuard, Ubiquiti UniFi). Two firewalls are configured to build an encrypted tunnel between them over their regular internet connections. Once the tunnel is up, devices at one office can reach devices at the other office as if they were on the same extended network.

The tunnel is encrypted (IPsec or sometimes WireGuard), routes the right traffic over the right path, and consumes essentially zero incremental cost beyond what the firewalls already do. Most SMB-class firewalls support 5 to 50 concurrent site-to-site tunnels, which is more than any SMB needs.

What it works well for. 2-3 offices with modest cross-site traffic. Cloud-first businesses where most daily work goes to the internet directly and the tunnel is only used for occasional access to on-prem resources or remote desktop into a server at headquarters. Backup traffic between sites overnight.

Where it strains. Real-time workloads (VoIP between sites, video calls that bridge through a central conferencing server). Centralized management – each tunnel is configured manually at both ends, and policy changes mean touching every firewall. Failover between multiple internet paths at each site – the firewall picks one tunnel as primary, fails over slowly, and may need manual intervention to fail back.

Real cost. $0 to $200 incremental per site if you already have business firewalls. The connections themselves run $50 to $500 per month per office, which you were already paying for.

2. SD-WAN

When site-to-site VPN over commodity internet is no longer enough, SD-WAN is the next step up. The article on SD-WAN for small business: is it worth it covers the technology in depth. The short version for the multi-site case: SD-WAN gives every site multiple internet connections used simultaneously, intelligent failover in under a second, application-aware routing across sites, and centralized policy management.

For multi-site businesses, the centralized management is often more valuable than the routing intelligence. With SD-WAN, “all sites have the same firewall rules” is enforced from a controller, not a hope. New sites get provisioned by shipping an appliance to the location and letting it pull configuration on its own.

What it works well for. 3+ offices, especially with VoIP or real-time business applications. Multi-site businesses with compliance requirements (HIPAA, PCI, SOC 2) where consistent policy across sites is auditable. Businesses with thin IT staff that cannot tour every site to push changes.

Where it strains. Single-office businesses (overkill). Businesses without internet diversity in some of their locations – SD-WAN cannot route around an outage if the location only has one ISP available. Businesses that will not configure application policies (the default behavior is roughly dual-WAN firewall, so the differentiated value requires tuning).

Real cost. $200 to $500 per month per site for appliance, license, and centralized management, on top of the connections themselves. The cost math improves with each added site because the management surface stays roughly flat.

3. MPLS – rarely the right answer at SMB scale

Multiprotocol Label Switching is a carrier-provided dedicated private link between sites. The traffic does not ride the public internet – it goes through the carrier’s MPLS backbone with predictable latency, guaranteed bandwidth, and an SLA. Until about 2018, this was how serious multi-site businesses connected offices.

At SMB scale today, MPLS rarely fits. A typical MPLS circuit runs $500 to $2,000 per month per location for bandwidth that you could get over commodity broadband for $80 to $300. The MPLS reliability advantage (carrier-grade SLA, predictable performance) is real, but the cost difference is large enough that most SMBs would rather spend the savings on SD-WAN over commodity links and accept the slightly different reliability profile.

Where MPLS still wins. Industries with very tight latency requirements (some financial services, real-time control systems). Regulated industries where the carrier SLA is part of the compliance posture. Businesses with international offices in countries with unreliable commodity internet.

Real cost. $500 to $2,000 per month per circuit, with multi-year contract terms and significant install costs at each site.

For most SMBs evaluating multi-site connectivity, the right move is to assume MPLS is not the answer unless a specific compliance, latency, or international-presence requirement says otherwise.

4. Point-to-point dedicated fiber

A dedicated dark fiber or wavelength link between two sites in the same metro area. Speeds are typically 1 Gbps to 10 Gbps, with no upstream bandwidth limits and no shared backbone congestion. The link is just a long Ethernet cable between two switches.

Where this fits. Same-city offices where the business needs near-LAN performance between sites (a manufacturer with a production floor across town from the office, a hospital with multiple campuses sharing imaging systems). Same-building or campus situations where the carrier can run fiber between buildings for a flat monthly fee.

Real cost. $1,000 to $5,000 per month per link, plus one-time install costs that can run $5,000 to $50,000 depending on whether the carrier needs to lay new fiber.

This is an edge case at SMB scale. The vast majority of small businesses do not need this much bandwidth between offices and cannot justify the cost.

How shared resources actually move between sites in 2026

The connectivity option is half the picture. The other half is what is actually moving across the connection.

File access

The on-prem file server pattern – a Windows file server at headquarters, branches reaching back over VPN to mount network drives – works but is the slowest path. SMB protocol over a 50 ms cross-site link feels noticeably slow compared to local access. File operations that would take 2 seconds locally take 10-20 seconds across the link.

The modern alternative is SharePoint or OneDrive with offline sync enabled on each user’s laptop. Files live in the cloud, get synced down to each user’s device, and stay current. A branch office user opens a file and it is local on their laptop. They save it, and the change syncs back to the cloud and out to anyone else who has that file synced down.

For businesses that genuinely need on-prem file servers (large datasets, regulatory restrictions, legacy applications that demand SMB file paths), the right approach is usually a local file server at each site with replication between them rather than reaching across the link for every file.

Identity and authentication

The old model was a domain controller at headquarters and a read-only domain controller at each branch for performance. The new model is identity in Entra ID with user authentication going to the cloud from anywhere.

Hybrid identity (Entra ID synced with on-prem Active Directory) is the realistic state for most SMBs that are not greenfield. Branches authenticate to the cloud for most things and to the local AD for legacy applications. The cross-site link is not on the critical path for daily login.

Printing

Print servers were a classic reason to need branch-to-headquarters connectivity. Today, the standard is universal print services (Microsoft Universal Print, PaperCut, vendor-specific cloud print) where each printer registers with a cloud service and any authorized user can print to it from anywhere. The cross-site link does not need to carry print jobs.

Phones

VoIP between sites is one of the genuine remaining reasons to care about cross-site connectivity quality. A hosted phone system (RingCentral, 8×8, Zoom Phone, Microsoft Teams Phone) treats every site as a separate connection to the cloud, which removes the cross-site dependency entirely. An on-prem PBX with extensions across sites still needs reliable, low-latency cross-site links.

Hosted phone systems are the right answer for most multi-site SMBs in 2026. The cost difference vs maintaining an on-prem PBX with cross-site connectivity is large, and the resilience profile is better (a site can keep using phones even when its local connection is down, by routing calls to mobile devices).

Line-of-business applications

The line-of-business application is the variable. If it is SaaS, every site reaches it independently over the internet and the cross-site link is irrelevant. If it is self-hosted in the cloud (Azure, AWS, Google Cloud), same story. If it is on an on-prem server at headquarters, every branch user is making a round trip to headquarters every time they use it.

For an SMB still running on-prem line-of-business applications, the cross-site connectivity decision usually hinges on this workload. The right move in many cases is to host the application in Azure or AWS, which collapses the cross-site dependency into “every site reaches the cloud.”

What changes at 2, 3, 5, and 10 locations

2 locations

The connection question is simple. A pair of business firewalls, a site-to-site VPN tunnel between them, and the work is done. Each site has its own internet, the tunnel carries the few resources that cross between them, and failure of the tunnel does not kill either site – it just disconnects them temporarily.

Total incremental cost for the multi-site piece: roughly zero, assuming both sites already needed business firewalls anyway.

3 locations

Site-to-site VPN still works but the management surface starts to feel it. Three tunnels (full mesh) or three sites connecting back to a hub, depending on traffic patterns. Policy changes mean touching three firewalls. The “is the network healthy” question now requires checking three sets of dashboards.

This is the threshold where SD-WAN starts to make sense if any of the following are true: real-time traffic between sites, compliance requirements that need consistent policy enforcement, or an IT generalist who is spending visible time on per-site policy.

5 locations

Site-to-site VPN with hand-managed configuration is operationally painful at five sites. Each site needs its own ISP relationship, its own firewall config, its own monitoring. New application access rules mean five firewall logins. Verifying that all sites are at the same security baseline becomes a project.

This is the threshold where SD-WAN typically pays for itself in management time, even before considering the routing benefits. A five-site SD-WAN deployment also opens the door to centralized cloud-managed Wi-Fi (Meraki, Aruba Central, Ubiquiti UniFi cloud) which simplifies the other half of the network.

10 locations

At 10 sites, the question is usually about how the business handles networking as a continuously operated service rather than a project. Multi-site management at this scale needs a real operational pattern: central monitoring, alerting, change windows, configuration baselining, periodic audits, vendor management for the underlying connectivity.

Most SMBs that get to 10 locations have either built an internal IT team capable of running this, or have handed it to a managed network provider. The DIY-via-spreadsheet pattern that works at 2-3 sites breaks at 10. The conversation usually shifts from “what equipment do we buy” to “who is operating this.”

Cost math per added site

Real numbers, all-in for the multi-site piece (not counting the cost of each site’s existing internet, which the business pays anyway).

Connection model	Initial cost per site	Monthly cost per site (multi-site overhead)
Site-to-site VPN, manually configured	$0-$500 (already have firewall)	$0-$50 (per-site management time)
Site-to-site VPN, managed by MSP	$500-$2,000 (config and onboarding)	$100-$300
SD-WAN, self-managed	$1,500-$4,000 (appliance + license setup)	$50-$200 (license amortized)
SD-WAN, managed	$1,500-$4,000 (appliance + license setup)	$200-$500
MPLS	$500-$5,000 (install)	$500-$2,000 (circuit)
Dedicated fiber	$5,000-$50,000 (install)	$1,000-$5,000 (link)

The cheapest viable starting point at SMB scale is site-to-site VPN over the firewalls each site already has. The most common upgrade path is to SD-WAN somewhere between 3 and 5 sites, when the centralized management starts to be worth the per-site overhead.

How shared resources affect the connectivity choice

Two businesses with three offices each can have wildly different cross-site bandwidth requirements depending on what they share.

Cloud-first business. Microsoft 365, SharePoint, hosted line-of-business app, hosted VoIP. Cross-site traffic is essentially zero except for occasional file copies and remote desktop into the rare on-prem resource. Site-to-site VPN over normal business internet handles this without strain.

Hybrid business with on-prem file server. SharePoint for some files, an on-prem file server at headquarters for large datasets that have not moved. Branches reach back to the file server over the cross-site link. The link carries roughly 5-50 Mbps of sustained file traffic during business hours, with spikes higher. A 100 Mbps business cable connection at each site is fine for this; a 10 Mbps DSL is not.

On-prem-heavy business. Active Directory at headquarters, file servers, ERP, custom line-of-business apps, on-prem PBX. The cross-site link is on the critical path for almost every workflow. Failure of the link halts work at the branches. This is where dedicated bandwidth (MPLS, dedicated fiber) or genuinely high-quality SD-WAN with cellular backup starts to be worth its cost. It is also the situation that most strongly argues for cloud migration of the on-prem workload.

Common mistakes

The mistakes that turn a multi-site network into a recurring source of pain.

1. Treating the second office like a new island. Each office gets its own DHCP scope, its own DNS, its own AD site, its own everything, with no coordination. Six months later, users at one office cannot find a resource at another and nobody knows why.
2. No diversity in cross-site paths. Two offices in the same metro area both buy fiber from the same carrier in the same conduit. A backhoe takes both sites offline at once.
3. Sizing the cross-site link for current load only. The cross-site link is fine for what runs across it today, but every new application that gets added quietly adds to the traffic. Two years in, the link is the bottleneck and nobody knows when it crossed over.
4. Skipping the site-to-site VPN documentation. The tunnel was set up two years ago, the engineer who did it left, and now nobody knows the IPsec parameters or which firewall is the initiator. The first time it breaks, the business has to rebuild the tunnel from scratch.
5. Putting the on-prem file server at a branch office. The branch has worse internet, worse power, worse physical security, and nobody onsite to deal with hardware issues. Authoritative copies of business data should live at the most reliable site, not at the closest one to the person who asked for them.
6. Not failing over the cross-site link. Single site-to-site VPN tunnel between sites with no backup. When the headquarters internet goes down, branches lose access to shared resources for the duration of the outage.
7. Mixing identity systems across sites. Site A uses local Active Directory, site B uses Google Workspace, site C uses Entra ID. Users at any site cannot reach resources at the other sites without separate accounts.
8. Inconsistent firewall configuration. One site has IDS/IPS enabled, another does not. One site has DNS filtering, another does not. Compliance audits find this; so do attackers.
9. No central monitoring. Each site is monitored separately or not at all. Outages at branches get discovered when a user calls in, not when the monitoring system alerts.
10. Building the inter-site network without consulting the cloud strategy. The business is six months into a Microsoft 365 migration that will eliminate 80% of the cross-site traffic. The IT team builds out a high-bandwidth SD-WAN deployment sized for the old workload. The investment becomes obsolete before it finishes paying off.

Time-to-value

Activity	Typical duration
Multi-site design with an existing single office	1-3 weeks
Hardware procurement and shipping	2-4 weeks
New office buildout (firewall, switch, Wi-Fi, internet install)	4-8 weeks (gated by ISP)
Site-to-site VPN configuration between two existing sites	2-5 days
SD-WAN deployment per site	1-2 weeks
Full multi-site SD-WAN rollout at 5 locations	8-16 weeks
Migration of on-prem resources to cloud (file server, AD, applications)	2-9 months

The longest-lead item in any multi-site project is almost always internet install at the new location. Carrier install windows for business fiber can stretch 6-12 weeks even when the building is already lit. Plan around that, not around the equipment.

When to hand multi-site networking to a managed provider

The DIY threshold for multi-site networking is lower than the single-site threshold. At a single location, a competent IT generalist can run the network, the firewall, and the Wi-Fi successfully for years. At three or more locations, the operational pattern that makes single-site work – reactive troubleshooting, ad-hoc changes, monitoring by walking the office – stops scaling.

Signs the business has crossed into “this needs a managed network provider” territory: configuration drift between sites that the team did not catch until something broke, recurring user complaints about cross-site access that take days to diagnose, “we have not patched the branch firewall in 18 months” admissions, audit findings that point to inconsistent policy enforcement, or the IT generalist spending more than 25% of their week on network issues.

A managed network provider running multi-site networks brings the operational pattern that single-site IT does not have: change windows, configuration baselining, central monitoring, alerting on actual incidents not noise, vendor management for circuits and equipment, and accountability for the network as a whole rather than as a sum of sites. This is also the natural entry point into broader managed IT services for businesses that have not engaged an MSP yet.

How multi-site fits with the rest of the network

The multi-site question sits on top of every other network decision. The pieces that need to be consistent across sites:

• Firewall selection. Same vendor and model family across sites is dramatically easier to operate than one vendor at headquarters and another at the branch. Centralized management features (Meraki Dashboard, Fortinet FortiManager, SonicWall Capture Security Center) only work within a vendor.
• VLAN design. Use the same VLAN numbering and segmentation pattern at every site. A user at site A who switches to working from site B for a day should land in the same logical segment.
• Managed switch consistency. Same vendor and management approach across sites simplifies operation. Most SMB-class managed switches now support cloud-based central management at no extra cost.
• Business Wi-Fi consistency. Cloud-managed Wi-Fi (Meraki, UniFi cloud, Aruba Central) is the right answer at multi-site scale. A roaming user at any site gets the same SSID and the same auth experience.
• Redundant internet at every site. Single-ISP dependency multiplies across sites – if any one site goes down and that site is the cross-site hub, the whole network is degraded.
• Network monitoring. Centralized monitoring of all sites with one dashboard. Per-site standalone monitoring is operationally untenable past two sites.

The takeaway: design the multi-site network as one network across multiple locations, not as multiple independent networks that happen to share a tunnel. The operational benefit of treating it as one network compounds with each added site.

How Sequentur can help

If you are planning a second office, refreshing a multi-site network, or struggling with cross-site connectivity at your current locations, schedule a call.