Connecting Two or More Offices Without Building a WAN You Cannot Afford

You have just opened a second office and someone has asked how to connect it to the first one. In most Australian SMEs in 2026 the correct answer is that you do not connect them at all. Both sites get their own internet service, both reach the same cloud services independently, and there is no tunnel between them.

A site-to-site link is not a default. It is a specific answer to a specific dependency, and if you cannot name the dependency in one sentence, you do not have one.

The ladder, in order of cost and complexity

There are four honest options and they are not equally likely to be right.

Option one: nothing. Two independent sites, each with its own internet connection, firewall and wireless. Identity, email, files, phones and line-of-business applications are all cloud services that both sites reach over the public internet. Nothing at site B depends on anything at site A.

Option two: a site-to-site VPN. An encrypted tunnel between the two firewalls so that devices at one site can reach devices at the other by IP address. Cheap, well understood, and the source of most of the problems in this article.

Option three: SD-WAN. Software-defined WAN, which in practice means a managed overlay that builds and monitors tunnels automatically across whatever underlying links you have, steers traffic by application, and fails over between links when one degrades. Both major SME platforms include it: Ubiquiti’s Site Magic in UniFi Site Manager automates tunnels between UniFi gateways, and Cisco Meraki’s Auto VPN does the same across the Meraki dashboard, with the application-aware path selection and cellular failover behaviour sitting under the Secure SD-WAN Plus licence edition.

Option four: a carrier-provided private link. A Layer 2 or Layer 3 service bought from a carrier that joins the two sites as if they were one network, with a contractual service level attached. In Australia this generally sits on dedicated fibre, of which nbn Enterprise Ethernet is the wholesale product, delivered over point-to-point fibre with symmetrical speeds. The carrier owns the path and the fault.

When each one is actually justified

Take option one, nothing, unless you can name the dependency. This is right for the large majority of professional services, retail, health and trades businesses opening a second location in 2026, because their entire working set is already in Microsoft 365 or Google Workspace. Two independent sites is not a compromise. It is a more resilient design than a hub and spoke, because a failure at head office does not take the branch offline.

Take option two, site-to-site VPN, when a small number of specific systems live at one site and are needed at the other. A practice management server, a CAD or drawing store, a line-of-business database, a legacy application that has to be on a LAN. The tunnel is justified by named systems and it is sized around those systems, not around everything.

Take option three, SD-WAN, when you have three or more sites, or when the link genuinely matters. The value is not the tunnel, it is not having to build and maintain each tunnel by hand, and having a console that tells you which link is degraded before staff do. If you already run UniFi or Meraki across both sites, you effectively have this available already, so the question is only whether to turn it on. Where SD-WAN earns its keep is failover: two internet services at each site with automatic path selection turns a carrier outage into a slow morning rather than a closed office.

Take option four, a carrier private link, only when you have a real-time dependency with a contractual consequence. Voice or video that must not degrade, a clinical or manufacturing system with a latency requirement, a data replication obligation with a recovery time objective you have committed to in writing. Note that the relevant part of the purchase is the service level rather than the bandwidth. nbn Co lets providers add enhanced service levels to business services, defined across an operational period (the hours during which faults can be worked), a response time, and a rectification time for faults within nbn’s control. That is what you are buying. Bandwidth you can buy anywhere.

Before you price any of this, check what nbn technology serves each address, because the two sites may be on completely different technologies with completely different upload capability, and that alone can settle the design. In the outer east and the Dandenong Ranges in particular, the address determines the option set more than the budget does, which we cover in business internet in the outer east.

The real problem is identity and file access, not the tunnel

Businesses ask how to connect two offices when the question they actually have is how someone at site B logs in and opens a file that someone at site A created. Those are different problems and only one of them is solved by a network.

Identity has to be single, and it does not care where the person is sitting. One directory, one account per person, one set of multi-factor authentication and conditional access rules, applied consistently at both sites. If site B was set up in a hurry with its own local accounts, or its own tenancy, you have created two of everything: two joiner processes, two leaver processes, and one account you will forget to disable. In a Microsoft environment this means Microsoft Entra ID as the single authoritative directory with Conditional Access doing the policy work, and in a Google environment it means single sign-on configured at the Workspace level. Whichever you use, the answer is one directory, not one per building.

File access is where the tunnel gets built for the wrong reason. If both sites work out of SharePoint, OneDrive or Google Drive, there is nothing to connect: both sites reach the same service over the internet and the local cache on each laptop does the rest. If there is a file server at head office, a VPN will make it reachable from the second site and it will be miserable to use, because opening a large file over a WAN link is not the same experience as opening it over a LAN. The correct fix is almost always to move the files to cloud storage, not to buy a bigger tunnel. Do it before you open the second site if you can.

Whichever way the files go, they need to be backed up independently of either site, and you should know where your data actually lives before an audit or a client security questionnaire asks you.

Printing and phones: two small problems with different answers

Printing is not a WAN problem and should never be one. Nobody at site B should print to a printer at site A. Each site has its own printers, and the only thing that needs to be central is the print management and driver deployment, which modern cloud print services and endpoint management handle without any site-to-site connectivity. If your current design routes print jobs across a tunnel, that is a leftover from a print server that should have been retired.

Phones are genuinely easier across sites than within one site. A cloud or hosted phone platform treats both offices as extensions of the same system, with internal extension dialling, shared call queues, a shared receptionist and one set of numbers, and none of it depends on a link between the buildings, because both sites register to the platform independently. This is the single strongest argument for getting off any phone system with physical dependency on a building before you open the second site, and the options are compared in choosing a business phone system.

What phones do require at each site is a decent upload path and quality of service configured locally. Voice quality problems at a branch are nearly always a local internet or local network issue, not a distance issue.

“The second site feels slow” is almost never the second site

This complaint arrives within a month of opening and it is worth knowing what it usually turns out to be, because the reflex fix (buy more bandwidth) almost never works.

• All internet traffic is being hairpinned through head office. Someone built the tunnel as a default route so the branch would inherit head office’s firewall and filtering. Now every Teams call, every web page and every cloud file request at site B travels to site A and back out, adding latency to everything and limiting the branch to head office’s upload speed. This is the single most common cause.
• DNS is pointing at a server at the other site. Every lookup crosses the tunnel. If the tunnel wobbles, the branch appears to lose the internet entirely even though its own connection is fine.
• A file server at head office is being used as if it were local. See above. Bandwidth does not fix latency and file protocols are latency sensitive.
• Head office’s upload speed is the ceiling. If site A is on an asymmetric service, every branch user is sharing that upload. This is why the head office link, not the branch link, is usually the one that needs upgrading.
• It is not the WAN at all, it is the wireless. Access points placed by eye in a new fit-out, or a single access point covering a floor plate it cannot cover. Test with a laptop on a cable before you blame the link.

Diagnose in that order. The number of times the answer has genuinely been “the branch needs a faster internet service” is much lower than the number of times it was assumed.

Do not build something that needs a network engineer to change

This is the constraint that should shape the whole design, and it is the one that gets ignored because the person building it is comfortable with complexity.

A two-site network in a 40-person business will be modified by whoever is available on the day: a new VLAN for a camera system, a firewall rule for a new application, a subnet change because someone bought a new appliance. If those changes require reading a routing table, the business is now dependent on one person or one provider, and every change becomes a ticket with a lead time.

Three rules keep it maintainable:

1. Use non-overlapping, obvious IP addressing from the start. Site A on one clearly numbered range, site B on another, with room to add site C. Two sites that both use 192.168.1.0/24 cannot be joined without renumbering one of them, and renumbering a live site is a weekend nobody enjoys.
2. Keep both sites on the same platform and the same management console. Whatever you pick, pick one, so that a change looks the same at both sites. This is a real argument in the platform you choose for each site, and it is why the automated overlay options are worth more than their feature lists suggest: they generate the tunnel configuration rather than asking a human to.
3. Write it down. The addressing plan, the tunnel endpoints, the firewall rules and why each one exists, the circuit IDs and carrier account numbers for both sites. If it is not written down where the next person can find it, the design is only as durable as one person’s memory.

The direction this is all heading, and why it argues for doing less

The reason “connect nothing” is a defensible answer in 2026 and would not have been ten years ago is that the security model has moved. Access decisions are increasingly made on identity, device compliance and context rather than on which network a device is plugged into, which is the premise behind SASE and zero trust network access as a replacement for the VPN. In that model, a tunnel between two buildings buys you very little, because being on the network is no longer what grants access to anything.

Practically, that means the money is better spent on identity and endpoint security than on the link. A second site with strong conditional access, managed devices and cloud file storage is more secure and easier to run than two sites joined by a flat tunnel, where a compromise at the branch reaches head office because the firewall between them was configured to allow everything.

A short decision path

Ask these in order. Stop at the first yes.

1. Is there a system at one site that people at the other site must reach directly by IP? If no, connect nothing. Give each site its own internet service and its own firewall, and finish.
2. Is it one or two named systems? Build a site-to-site VPN scoped to those systems only, not a default route, and plan to retire it when the systems move to cloud.
3. Do you have three or more sites, or does an outage at either site cost real money? Use the SD-WAN capability you already own in your network platform, with a second internet service at each site for failover.
4. Do you have a real-time dependency with a written recovery obligation? Buy a carrier private link with enhanced service levels, and buy it for the service level.

Most businesses stop at one. Some stop at two. Very few genuinely need four, and the ones that do usually know why.

If you are opening a second site in the next few months, the connectivity order and the identity design are the two things worth getting right before anything is installed, and both have longer lead times than people expect. Call TechAssist on 1300 028 324 or get in touch at https://techassist.au/contact/ and we will map the honest option for your two addresses. If the second site is also a relocation, work through the office move runbook alongside it.

Multi-Site IT for Melbourne Businesses: Branches, Warehouses and Pop-Ups

When a Melbourne SME opens a second site — a warehouse in Dandenong, a pop-up in the CBD, a branch in Geelong — IT complexity compounds fast. By the fifth site you are running thirty different NBN contracts and nobody knows where the spare switch lives. This is the practical playbook for keeping multi-site IT under control.

Identity first, network second

The single most important shift in multi-site IT thinking over the past five years is moving from a network-centric model to an identity-centric one. In the old model, a “site” was defined by its network — the same VLAN, the same domain controller, the same file share. Anyone connecting to that network was on the corporate LAN and had access to corporate resources.

In the new model, a “site” is largely a power and connectivity convenience. The corporate resources live in Microsoft 365, Azure, or other cloud services. Access is granted based on user identity, device compliance and conditional access policies — not based on which Wi-Fi the user happens to be on. This is the practical version of zero trust thinking, and it changes the multi-site IT problem from “extend the corporate network to each location” to “make sure each user has reliable internet and a compliant device, regardless of where they are”.

If you are still thinking in the old model, multi-site IT looks expensive and complicated — SD-WAN, MPLS, site-to-site VPNs, domain controllers at each branch. If you have already made the identity-first shift, it looks much simpler — good internet at each site, a sensible Wi-Fi standard, identity through Microsoft Entra ID with strong conditional access, and you are most of the way there.

For a 25-person professional services firm opening a second office in Hawthorn, the right answer in 2026 is almost never to extend the corporate network. The right answer is to put a business-grade NBN connection in, deploy a managed Wi-Fi system, and let identity do the rest of the work. We have done this transition for several Melbourne clients and it consistently reduces the per-site IT cost by 40 to 60 percent compared to the old model.

When SD-WAN is overkill

SD-WAN gets pitched aggressively to mid-market businesses by carriers and resellers because it is a high-margin product. For most Melbourne SMEs with one to three sites, it is overkill. Here is when it pays back and when it does not.

SD-WAN is overkill when:

• You have one to three sites and the WAN traffic is mostly to cloud services (Microsoft 365, Azure, Salesforce, etc.) rather than between sites.
• Site-to-site latency is not business-critical (you are not running real-time voice over a private WAN or replicating large databases between sites).
• Your existing internet links are reliable enough — business-grade NBN with a 4G failover usually is.
• You can solve specific site-to-site needs with point solutions (a managed site-to-site VPN for the one application that needs it, rather than SD-WAN for everything).

SD-WAN starts to pay back when:

• You have four or more sites with active site-to-site traffic.
• You are running voice or video that needs QoS guarantees you cannot get from the public internet.
• You have a real need for application-aware routing — sending Microsoft 365 traffic out the local internet break while sending finance system traffic back to head office, automatically.
• You have specific compliance or contractual requirements for traffic segregation that point-solution VPNs cannot meet.

The Box Hill construction firm we onboarded last year had three sites and was being quoted $4,200 a month for SD-WAN by their incumbent telco. The actual requirement was a reliable internet connection at each site, identity-driven access to cloud apps, and a managed VPN between head office and the warehouse for a legacy job costing system that did not have a cloud version. We delivered that for $1,150 a month all-in across the three sites and the legacy system was migrated to a cloud equivalent six months later, eliminating the VPN entirely.

The hardware standard kit

One of the unglamorous secrets of multi-site IT is that the per-site hardware should be boringly consistent. Same firewall model, same switch model, same access point model, same configuration template, every site. This makes troubleshooting fast, sparing strategy obvious, and refresh cycles predictable. We use a standard kit per site type, scaled to size.

The point is not the exact equipment choice. The point is consistency. Pick a vendor stack (we tend to favour Fortinet for SMB and Cisco Meraki for businesses where the simpler cloud-managed model is more important than the deeper feature set), document the standard configuration, and apply it everywhere. When the access point dies at the Geelong branch, a same-model spare ships overnight and a remote engineer can reconfigure it from the template.

The on-site support response time problem

This is the issue that bites every Melbourne SME the moment they open a second site, and it is almost never addressed in the original IT planning.

Same-business-day on-site support is easy to deliver in the Melbourne metro area. It is harder when the second site is in Ballarat, Bendigo, or further afield. Most national MSPs solve this by paying break-fix technicians on demand at country rates, which is fine for occasional incidents but expensive and inconsistent for ongoing operations.

The honest answer is that on-site response time is a zone-based pricing question. Our Tecoma headquarters and CBD office at 575 Bourke Street let us deliver same-business-day on-site support across the Melbourne metro footprint, and we are transparent about response times for outer-metro and regional locations. For a multi-site business, the right conversation is “what is your business tolerance for a Ballarat user being offline for 24 hours versus 4 hours, and what is that worth paying for?”. Often the answer is that day-to-day support is delivered remotely (which works for 90% of issues), and on-site is reserved for hardware replacement and physical incidents, with a defined hours-to-on-site SLA per site zone.

For an outer-metro warehouse where downtime costs $4,000 an hour, paying for 4-hour on-site response is good economics. For a regional branch with five staff doing administrative work where downtime costs $200 an hour, next-business-day on-site is the rational choice.

This is the conversation that should happen during multi-site planning, not after the first regional outage. Zone-based response SLAs need to be in the agreement, with the cost difference made explicit. Anyone who quotes you “same SLA at every site” is either charging you for outer-metro response everywhere, or going to disappoint you when the Geelong site goes down.

The three governance rules that stop site sprawl

Multi-site IT becomes a mess not because of any single bad decision, but because of dozens of small decisions made independently at each site over years. Three governance rules, applied from day one of multi-site operations, prevent this.

Rule 1: one ISP relationship, not thirty

The single biggest contributor to multi-site IT chaos is each site having its own ISP contract, billed separately, with separate account managers and separate support paths. By site five, you have five different ISPs, five different bill cycles, five different sets of router credentials, and an IT manager who is on the phone to a different call centre every week.

The rule: every site’s internet connection runs through one ISP relationship, ideally aggregated by a single business-grade provider that can deliver to all your locations. The cost is usually within 5-10 percent of buying separate connections, and the operational saving is enormous. When a site goes down, there is one number to call and one technical contact who knows your business.

This rule applies even when the underlying technology has to vary — NBN at one site, Enterprise Ethernet at another, 4G at a pop-up. The aggregator handles the underlying carrier; you handle one relationship.

Rule 2: every site has a documented sponsor

Each site needs a named business owner who is responsible for the IT environment there. Not the IT manager — the local business sponsor. They are the person who notices when something is broken, who escalates when remote support is not responding fast enough, who is the local point of contact for hardware replacement deliveries, and who signs off on local IT changes.

Without a sponsor, sites accumulate undocumented changes — the warehouse manager who hard-wired the printer to bypass print server policy, the branch manager who plugged a personal Wi-Fi extender into the corporate switch, the pop-up coordinator who set the firewall admin password to “password123” so the marketing agency could plug in their demo equipment. Each of these is a small problem. Cumulatively they are how site IT environments rot.

The sponsor does not need to be technical. They need to be accountable. We require this as a condition of taking on multi-site management contracts, because without it the support quality degrades over time no matter what we do.

Rule 3: hard quarterly site audits

Every site gets a documented audit every quarter. Equipment inventory, configuration check against the standard template, network performance baseline, security posture review, sponsor interview about what is working and what is not. This costs about two engineer-hours per site per quarter and is the single most effective control against drift.

The audit produces a list of variances from standard. Most are trivial and get fixed during the visit. Some surface real changes — a site has grown headcount and needs more capacity, the local landlord has changed the building’s electrical layout, a department has started a workflow that needs a different printer configuration. The audit is where these get picked up and handled deliberately, rather than being discovered during an outage.

This is part of how our managed IT services model works for multi-site clients — a structured operational rhythm rather than reactive break-fix.

Backup, disaster recovery and the multi-site twist

Multi-site businesses have an interesting backup and disaster recovery profile because the sites can serve as recovery locations for each other in many scenarios. A flood at the head office is bad, but if the warehouse has internet, power, and a few desks, head office staff can work from there for a fortnight.

The implication is that multi-site DR planning should explicitly identify each site’s potential role in a recovery scenario for each other site. Most of the time this just means making sure that staff from each site have credentials that work everywhere, that there is enough physical capacity to absorb displaced staff, and that critical applications are cloud-hosted and accessible from anywhere.

The legacy file server at head office becomes a single point of failure that breaks this model. So does the on-premises application that only works on the head office LAN. Modern backup and DR design for multi-site SMEs explicitly identifies these single points of failure and either eliminates them (move to cloud) or designs around them (replicate to a second site, document the recovery process). We have rebuilt backup and DR for multi-site Melbourne businesses where the original design pre-dated the second site by years and was still treating head office as the only thing that mattered.

The cloud-first multi-site stack

For a Melbourne SME starting fresh, or for one going through a multi-site refresh, the cloud-first stack is now the default. It looks like this:

• Identity: Microsoft Entra ID with phishing-resistant MFA and Conditional Access policies. No on-premises domain controllers anywhere.
• Devices: All endpoints enrolled in Microsoft Intune. Compliance policies enforced as a precondition for accessing corporate resources. Wipe capability for lost devices.
• Productivity: Microsoft 365 with SharePoint and OneDrive as the canonical document storage. No file servers.
• Line of business: Cloud-hosted wherever possible. SaaS for accounting, CRM, ERP. Where on-premises is unavoidable, hosted in Azure or AWS, accessed via published web app or Azure Virtual Desktop.
• Networking per site: Business NBN or Enterprise Ethernet, managed firewall, managed Wi-Fi, 4G failover. No site-to-site VPN unless required for a specific application.
• Voice: Microsoft Teams Phone or a comparable cloud PBX, with handset standards documented per site type.
• Print: Cloud print or per-site MFD with direct printing from Intune-managed endpoints.

This stack is genuinely site-agnostic. Adding a new site means provisioning internet, deploying the standard hardware kit, and confirming identity policies apply. The business systems do not change. The “cutover” for a new site is hours, not weeks.

This is also where cloud services design matters more than network design. The cloud stack is the thing the business runs on. The network is the dial tone.

Common multi-site mistakes we see

A few patterns come up repeatedly in multi-site engagements. Worth listing.

Buying the wrong internet at the new site. Going for the cheapest available NBN connection at a warehouse where 30 staff need to use cloud services is false economy. The right line at the right speed costs maybe $80 a month more and removes a category of frustration.

Not standardising on switch and access point models. Different equipment at each site means different troubleshooting, different sparing, different configurations. Pick one. Live with it for the refresh cycle.

Letting each site choose its own SaaS. The Geelong branch using a different scheduling tool than head office because “it works better for our team” is fine until a customer interaction crosses sites and the tools cannot talk to each other. SaaS standards are a head-office decision.

Forgetting the physical security of the comms cupboard. A switch in an unlocked corner of the warehouse is a security incident waiting to happen. Lock the rack, log access.

Not having a sponsor at each site. Already covered, but the most common failure mode.

Underestimating the support cost of regional sites. Same-business-day on-site in regional Victoria is genuinely more expensive than in Hawthorn. Build it into the budget honestly rather than hoping nothing breaks.

How TechAssist supports multi-site clients

We support multi-site Melbourne businesses across construction, manufacturing, logistics, professional services and healthcare. The model is per-user fixed monthly pricing with zone-based on-site SLA tiers, which means a client knows exactly what each user costs to support regardless of which site they sit at, and the on-site response commitment matches the business value of each location.

Our 24/7 NOC in Tecoma handles monitoring and remote response across all sites for all clients. Same-business-day on-site is available across the Melbourne metro area from our two offices — Tecoma and 575 Bourke Street CBD. For outer-metro and regional Victorian sites, the SLA is set during onboarding based on the business risk profile and is honest about response time and cost.

Founded in 2014, we have 13 Australian-employed engineers and run an Essential Eight aligned, ISO 27001 capable operations practice. The reason that matters for multi-site clients is that consistency across sites is a security and audit problem as well as an operational one. The same standards, the same monitoring, the same documentation, every site, every time.

If you are about to open a second site, or are managing three sites that have grown organically into a mess, we have done this enough times to know where the traps are. Have a look at our MSP Melbourne page for the broader service description.

Frequently Asked Questions

Do we need SD-WAN for our second site?

Almost certainly not. SD-WAN is a real product with real use cases but for most Melbourne SMEs with two to three sites running mostly cloud applications, a managed business NBN at each site with 4G failover is the better answer. SD-WAN gets pitched hard because it is high margin for the seller.

Should we have a domain controller at each branch?

No. If you are still thinking in those terms, the broader architecture probably needs a refresh. Identity should live in Microsoft Entra ID, devices should be Intune-managed, and the branch becomes a power-and-internet location rather than a network outpost.

How do we handle internet failover at a regional site?

4G or 5G failover through the firewall is the standard answer. The throughput is lower than the primary line but enough to keep cloud applications running while the NBN fault is being resolved. Telstra and Optus business mobile data plans are the usual carriers; choose the one with better coverage at the specific site.

What happens when a site needs urgent hardware replacement?

If the equipment is standardised across sites, we usually have a spare ready to courier the same day for Melbourne metro and next business day for regional. For sites where downtime is critical, we recommend keeping a cold spare on-site, configured and ready to swap. The cost is the price of a backup access point or switch, and it is cheap insurance.

Can we use the same Wi-Fi network name across all sites?

Yes, and we recommend it. Same SSID, same identity-based authentication (typically WPA3-Enterprise via Entra ID), automatic roaming for staff who move between sites. This is part of the identity-first design — the user does not need to know they are at a different site.

How do we budget for multi-site IT?

The two main components are per-user costs (which scale with headcount and are largely site-agnostic in a cloud-first stack) and per-site costs (which cover internet, hardware, on-site support response). A reasonable rule of thumb is to budget the equivalent of one month’s per-user fee per site per quarter for ongoing site-specific costs, plus the standard kit cost for new site setup.

What to do next

If you are about to open a second site, the right conversation is identity-first design, business NBN with failover, standardised hardware kit, and a documented site sponsor. Skip the SD-WAN pitch unless you are at four-plus sites with real site-to-site traffic.

If you are already running three or more sites and feel like the wheels are coming off, start with a site audit. Inventory what is at each location, who the sponsor is, what the ISP relationship looks like, and where the variances from a sensible standard have crept in. The list itself will tell you the priority order for cleanup.

If you want a hand designing or untangling multi-site IT for a Melbourne business, get in touch. We will give you a frank assessment and a realistic plan.