An attorney in one office needs a document stored in another. A remote desktop slows down while a team joins a video meeting. A branch loses its internet connection shortly before a filing deadline.
These are network design questions as much as internet-speed questions. A firm with several offices needs a consistent way to connect its locations, reach applications and respond when a connection degrades.
SD-WAN provides an approach worth evaluating for that work. Calling it a new standard describes a practical design benchmark, not a mandatory technology for every firm. Its value depends on the problems it solves and how well it is operated.
What SD-WAN changes
A software-defined wide area network uses centrally managed policies to control connectivity across locations. It operates over underlying connections such as internet circuits and private network services.
For example, Cisco's SD-WAN platform provides centralized configuration and policy management across branches. [1] This can give a network team a consistent operating approach instead of treating every office as a separate configuration exercise.
The service still needs suitable circuits, equipment and configuration. Purchasing SD-WAN does not supply unlimited bandwidth or remove the need to manage the network beneath it.
Choose paths for the application experience
A connection can remain online while performing poorly. Latency, variation in delay and packet loss can affect the work carried over it.
Cisco documents application-aware routing that measures path characteristics and selects transport tunnels according to defined application requirements. [2] Capabilities and behavior vary by product and configuration, so ask what the proposed platform actually measures and controls.
For a law firm, begin with the workflows: document access, hosted practice applications, voice, video and remote desktops. Decide which need low delay and which can tolerate slower completion.
Then test the policies with real tasks. A backup upload and an interactive session may compete for capacity. A suitable design should reflect their different needs and verify the result from the user's perspective. A better route will not correct a slow database or an overloaded application server.
Connect offices around shared work
For a fictional example, a firm has four branches that need access to centrally hosted applications. Some traffic must reach that environment, while cloud services can be accessed through other approved paths.
Map those destinations before choosing the topology. Requiring every cloud request to travel through one office can introduce a dependency on that office's equipment and connection. Direct cloud access may be appropriate where the security design supports it.
Document routing, identity services, name resolution and application dependencies. A shared network provides reachability; the application's permissions still determine who can open a matter or document.
Evaluate the path to any private cloud environment separately. Internet access, office-to-office connectivity and a private cloud connection are related but distinct services.
Use backup connectivity as a tested capability
Multiple connections can provide alternative paths, but the firm must understand what happens when the primary path fails or becomes unusably slow.
Test both conditions. How quickly is the problem detected? Which traffic moves? What happens if the backup has less capacity? What happens when the primary returns?
Do not assume that every call, file transfer or authenticated session will continue without interruption. Session behavior depends on the platform, addressing, routing and application. Make it an acceptance test for the proposed design rather than a general promise.
A smaller backup circuit may support essential tasks if nonessential traffic is limited. Decide which work must continue during an outage and verify that the backup can support it under realistic load.
Two invoices do not establish two independent paths
Ask where the connections share infrastructure: building entrances, ducts, local access providers, equipment and power. Two carrier names can still conceal a shared failure point.
The same design principle appears in Microsoft's ExpressRoute resilience guidance, which considers physical diversity and redundant connectivity. [3] For office internet, investigate the actual service paths rather than assuming provider diversity is enough.
Where practical, use different access paths or technologies to address relevant failure scenarios. Wireless backup may help with a wired-path failure, but it introduces coverage, capacity and power considerations of its own.
Keep security controls explicit
SD-WAN can support network segmentation and integrate with security services, but the proposed capabilities need to be specified. Cisco describes segmentation and centralized policy controls in its platform. [1]
Define what each network segment can reach. Guest access should not create a route into client systems. Vendors should receive the access needed for authorized work. Matter-specific restrictions still need enforcement in document and application systems.
Protect the management environment as well. Cisco's hardening guidance addresses limiting administrative access, controlling reachability and protecting its control components. [4] Apply suitable authentication, role permissions, software maintenance and logging to the platform your firm chooses.
Encryption of a network tunnel does not replace endpoint protection, user authentication or application authorization. Treat each as part of the overall design.
Evaluate the operating service as well as the product
Ask who monitors path quality, investigates recurring degradation and coordinates with carriers. Confirm who approves policy changes and how the firm receives incident updates.
Useful reporting connects network events to business effects: which offices were affected, how long disruption lasted, whether traffic moved successfully and what still needs correction.
| Requirement | What to validate | Why it matters to the firm |
|---|---|---|
| Application performance | Representative tasks on normal and degraded paths | Tests usability rather than relying on link status |
| Office connectivity | Reachability and permissions for required resources | Supports collaboration without broadening access unnecessarily |
| Backup operation | Failure detection, traffic movement and session behavior | Establishes what work continues during disruption |
| Backup capacity | Essential workloads under realistic load | Avoids an alternative path that cannot support the office |
| Path independence | Shared access infrastructure, power and equipment | Identifies common failure points |
| Security | Segmentation, management access and logging | Defines the controls around the network |
| Operations | Monitoring, escalation and change responsibilities | Makes ownership clear after deployment |
Decide whether the added capability is justified
SD-WAN deserves serious consideration when the firm has several offices, multiple connections, complex cloud paths or recurring problems with routing and visibility.
A simpler environment may be adequately served by a well-managed firewall and tested dual-connection design. Compare the capabilities and operating effort against the needs of the firm. Avoid paying for complexity that does not solve a defined problem.
Start with a branch pilot. Record baseline task performance, validate security rules, introduce controlled connection failures and check the user experience during recovery. Expand when the design meets agreed criteria and the team can support it.
The benefit of SD-WAN is a more deliberate way to manage connectivity across the firm. It should make performance, access and continuity easier to understand and operate.
Allnext Legal helps law firms assess office connectivity, design SD-WAN environments and manage the network around their applications and daily workflows.
Sources
Connect Your Offices With Confidence.
Contact us
