A branch cutover that drops EFTPOS, prevents access to cloud applications or sends critical traffic over an untrusted path is not a networking inconvenience. It is an operational incident. This SD WAN migration guide is designed for Australian organisations that need to modernise branch connectivity without creating avoidable downtime, security gaps or a larger support burden.
The objective is not simply to replace MPLS or add a second internet link. A successful migration establishes consistent security controls, predictable application performance and a supportable operating model across every site. That requires design discipline before equipment reaches a branch.
Start the SD WAN migration guide with business outcomes
SD-WAN projects often begin with a bandwidth or carrier-cost discussion. Those matters are relevant, but they are not sufficient design inputs. First define what the business must protect and improve. For a retailer, that may mean payment systems and guest Wi-Fi remain isolated while stores retain connectivity during a primary-link outage. For a professional services firm, it may mean stable access to Microsoft 365, secure remote access and controlled use of SaaS applications. For an industrial site, local service continuity may matter more than low latency alone.
Document the outcome for each branch type, not just the average site. A head office, warehouse, small sales office and regional site may each need different link capacity, resilience and local services. Standardisation is valuable, but forcing an identical design onto fundamentally different sites often creates cost without meaningful protection.
At this stage, identify measurable success criteria. These should include application availability, acceptable failover time, voice and video quality, incident response expectations, visibility requirements and the maximum permitted outage window. Procurement can then compare carrier options and appliance sizing against actual operational needs rather than headline bandwidth figures.
Build an accurate view of the current environment
A migration is only as reliable as the discovery behind it. Legacy networks commonly contain undocumented static routes, local internet breakouts, third-party VPNs, printer networks, POS terminals, voice gateways and exceptions added during past incidents. These details tend to surface at the worst possible point: after the old circuit has been disconnected.
Create a site-by-site baseline covering the current WAN links, public IP addressing, LAN and VLAN structure, DHCP and DNS dependencies, wireless integration, voice services, cloud applications, remote-access requirements and any OT or IoT devices. Record which applications are sensitive to jitter, latency or session interruption. Do not rely only on configuration exports. Validate the information with local stakeholders and service owners.
It is also worth reviewing current traffic patterns. Many organisations discover that a large portion of branch traffic already goes to SaaS platforms or cloud-hosted workloads. Backhauling all of that traffic through a central data centre may no longer be efficient. Direct internet access can improve the user experience, but it must be paired with consistent inspection, web controls and logging. Otherwise, performance gains can come at the expense of security governance.
Identify dependencies outside the network team
Network changes can affect more than routing. Finance may own payment-provider connectivity. Facilities may manage building systems. A software vendor may require a fixed source IP address. A managed voice provider may have specific quality-of-service or SIP requirements. Include these owners in migration planning and obtain written acceptance criteria where practical.
This work can feel slow, particularly when the pressure is to deploy quickly. It is still cheaper than repeated after-hours site visits, emergency carrier escalations and rushed policy changes after go-live.
Design security and routing as one architecture
The appeal of SD-WAN is intelligent path selection across broadband, NBN, fibre, 4G or 5G and other available transports. The risk is treating it as a standalone overlay while leaving security policy fragmented across branch firewalls, cloud tools and legacy routers.
A unified secure SD-WAN design brings path selection, next-generation firewall inspection, segmentation, VPN connectivity and central management into the same operational framework. For many organisations, this reduces appliance sprawl and makes it easier to apply the same policy at every branch. It also gives security teams clearer visibility when application quality changes or a link begins behaving abnormally.
Define traffic classes based on business value. Payment traffic, voice, ERP, video conferencing, general web browsing, guest access and software updates should not all receive the same treatment. The design should specify preferred paths, performance thresholds, failover behaviour and security inspection requirements for each class.
There are trade-offs. Sending encrypted traffic for full inspection can require more firewall capacity. Local internet breakout may lower latency but expands the number of sites with direct exposure. Dual active links can increase resilience, yet carrier diversity is only genuine if the services do not share the same local access path or upstream failure point. A certified design should make these decisions explicit rather than assuming more links always means better availability.
Size for security services, not just throughput
Appliance sizing based only on firewall throughput is a common and costly mistake. Real-world performance changes when IPS, antivirus, application control, SSL inspection, logging, VPN services and SD-WAN functions are enabled together. Consider the number of concurrent sessions, expected growth, remote users, wireless traffic and the operational role of the device.
A smaller branch may suit a compact appliance, while a site running voice, local servers, high transaction volumes or multiple WAN links needs more headroom. Buying the lowest-priced model that meets a basic bandwidth figure can lead to an early replacement cycle. Best value is the design that meets the security requirement throughout its expected service life.
Use a pilot to prove the operating model
Do not make the most complex branch the first live migration. Choose a pilot site with representative applications, cooperative local users and manageable commercial impact. The pilot should validate more than whether the tunnel comes up. It should test policy consistency, application steering, failover, local breakout, alerting, log visibility, remote administration and recovery procedures.
Run realistic failure tests. Disconnect the preferred WAN circuit, introduce packet loss where the test environment permits, fail an overlay tunnel and confirm that critical applications take the expected path. Test both automatic recovery and the team’s ability to diagnose the issue from central management. If the only person who can resolve a branch fault is physically at the site, the design has not yet delivered the operational resilience it promised.
Capture the pilot results in a repeatable branch template. This template should include interface naming, VLANs, security zones, standard policies, application rules, monitoring thresholds and approved local exceptions. Templates reduce human error during rollout, but they should still allow controlled variations for sites with genuine technical differences.
Plan each cutover with a tested rollback path
A well-run cutover is deliberate rather than dramatic. Prepare the new SD-WAN appliance and central policies in advance, confirm carrier hand-off details, and schedule the work within an agreed maintenance window. Notify stakeholders of what will change, what they may notice and who is responsible for validation.
Before the cutover, take a configuration backup of the existing edge device and record current link status. During the change, validate local LAN access, DNS, critical applications, VPN connectivity, voice, payment services and monitoring. Do not declare success because a laptop can browse the web.
Every site needs a rollback decision point. Define the conditions that trigger it, the person authorised to make the call and the practical steps required to restore the prior service. A rollback plan that depends on unavailable staff, untested credentials or a carrier technician arriving after hours is not a plan. It is a hope.
For large estates, stage branches in manageable waves. Early waves should include enough variety to expose design issues, while later waves can benefit from a proven template. Avoid scheduling so many sites in one window that the support team cannot investigate multiple faults properly.
Operate, tune and govern after deployment
Migration completion is the beginning of the operational phase. Review link quality, application performance, security events and policy exceptions in the weeks after each wave. Thresholds that looked reasonable in a lab may be too aggressive for a regional broadband service or too lenient for a high-volume site.
Establish ownership for firmware lifecycle, configuration changes, carrier fault escalation, alert monitoring and incident response. Central management can make multi-site operations far more efficient, but only when change control and role-based access are properly defined. Maintain configuration backups and regularly test the ability to restore a device or rebuild a branch from a standard template.
Compliance requirements should also be reflected in the operating model. Retention of security logs, segmentation of payment environments, access controls and evidence of policy changes may be relevant to your industry or contractual obligations. Treat these requirements as design inputs, not paperwork added after deployment.
A secure SD-WAN rollout should leave the organisation with fewer disconnected controls, clearer visibility and a more predictable cost base. FortiSecure Store can help Australian teams align Fortinet hardware, licensing and certified deployment support to that outcome, so the migration is built for the branch network you operate now and the one you expect to grow next.