Connecting branch offices to the cloud

The problem

Connecting branch offices to the cloud often starts as a latency complaint. Someone at a satellite office says the ERP is slow, or calls drop at ten in the morning. The instinct is to blame the circuit. Half the time the circuit is fine and the traffic path is not.

Most branches were built one at a time. The firewall in one office is a different model from the one two time zones away. One site has fiber, another has business broadband plus a 4G stick in a drawer. Nobody wrote down the subnets. When a site goes down, an engineer drives over because the device is not reachable remotely.

Then the apps moved. Finance runs in the cloud, files sit in SharePoint or Google Drive, the phone system is SaaS. But the branch still sends everything to headquarters first, because that is where the old rules point. Every packet takes a detour, and voice, the least tolerant traffic, suffers first. Meanwhile each site still pays for a circuit sized for backhaul that no longer needs to happen.

What a good solution looks like

A good branch design is boring and repeatable. Pick one firewall model, one switch model, one access point model. Build a single configuration template where only the site name, local subnet, circuit handoff and local contact change. When every site is the same, a remote engineer can fix one from memory.

Assume two paths out of every branch. A primary circuit plus something cheaper that comes up on its own: a second broadband line from a different provider, or an LTE router. Test the failover rather than assuming it. A firewall that only fails over when the cable is unplugged will keep using a line that stays up and quietly drops packets.

Set traffic policy by application class. General web and SaaS break out locally at the branch. Internal apps in private subnets go through a tunnel or a private circuit. Voice gets its own queue and a priority rule that survives failover. Anything that must be inspected goes through the inspection point, and the rest does not.

Underneath sits addressing. One plan, written down, one block per site, room to grow. Keep guest, staff, voice and building devices such as cameras and badge readers on separate subnets. That decision alone makes security rules short and troubleshooting fast.

How to build it

Start by watching what a branch actually sends. Two weeks of firewall logs, or a mirror port with a flow collector, beats any survey. You will find the warehouse scanner talking to an on-prem server all day, or half the traffic is video that should never have been backhauled.

Then tier the sites. A 200 person office with a data closet, a small office in a shared building and a one-room sales office do not need the same kit. Two or three tiers keeps spare stock simple and the rollout predictable.

Build one reference site and run it for a month before touching the rest. Pull the primary circuit during a call and watch what happens. Measure latency to the main apps from the staff network and from guest Wi-Fi. Fix the template, not the site.

For the rollout, use zero touch provisioning: register the serial number, ship the device, have someone on site plug in power and uplink, and let it pull its configuration. Book a cutover window, keep the old path configured for a week so you can swing back, and move DNS and DHCP settings in steps rather than all at once.

Risks and how to manage them

Circuit lead times kill schedules. Order early and accept that a site may run on LTE for a few weeks. Make sure the firewall treats that link as a real path, not a backup that never carries traffic.

Overlapping IP ranges are the second trap, usually from an acquisition. Two sites on 192.168.1.0/24 cannot both route into the same cloud network. Renumber properly, or use NAT at the edge as a stopgap and put the renumber on a dated plan.

Physical single points of failure get forgotten. One firewall, one switch, one power strip. A branch that loses its only switch is offline even with a healthy circuit. Keep a spare switch and access point at larger sites or at a regional depot.

Edge security needs care. Guest Wi-Fi must not reach the staff network. Cameras, door controllers and printers belong on their own segment with narrow rules. If someone plugs a consumer router into a wall port, the switch should shut the port or move it to a quarantine VLAN instead of bridging it into the staff subnet.

How to measure success

Track time from order to a working site. That number tells you whether the template is good. Then track site visits per quarter: if engineers keep driving to branches, the remote management path has a hole in it.

Measure latency and packet loss from every site to your main apps, every minute, not just when a ticket arrives. Alarm on the trend as well as on a device going down. A circuit losing two percent of packets passes a ping test and still ruins calls. Also watch the share of traffic that breaks out locally versus backhauled. If backhaul is still high after six months, the routing policy never got finished.

Count tickets by site and category, and review them monthly with the network owner. For teams that want a second opinion before a big design decision, an outside review is often cheaper than a rebuild. The Cloudverg Expert architecture session is a 90 minute call at $450 with a written summary, and it sits alongside vendor professional services or a review from your own network team as one option among others.

Frequently asked questions