Implementing SD-WAN: A Step-by-Step Deployment Guide

Start with the outcomes you want, such as faster cloud access, lower circuit cost, better voice quality, quicker site turn-up or simpler management. Rank them, because they pull in different directions. Then record the starting point so you can show improvement.

• The list of sites, with size, user count and criticality.
• Current circuits at each site, with type, speed, provider, contract end date and monthly cost.
• The applications that matter, including voice, video, cloud services, line-of-business systems and file transfers, and where each one lives.
• Measured performance, including latency, jitter, packet loss and utilization, at busy times.
• The current security design, including where firewalls and web filtering sit.
• Known pain points, with examples and dates, so you can test them later.

If you are still deciding whether SD-WAN is right, the SD-WAN overview and the SD-WAN and MPLS comparison cover that decision.

Topology

Choose how sites connect. A hub-and-spoke design routes branch traffic through one or more central sites. A full mesh lets every site connect directly to every other site. Many designs use a partial approach, with hubs for data centre traffic and direct paths between selected sites, such as those that exchange voice or large files.

Internet and cloud access

Decide whether branch traffic to the internet and cloud services will break out locally or travel through a central security stack first. Local breakout reduces delay and saves central bandwidth, and it requires security at the branch or in a cloud-delivered security service. Backhauling keeps one inspection point and costs bandwidth and time.

Security model

Decide where firewalling, web filtering and threat prevention will run. Options include security functions built into the SD-WAN device, a separate firewall, or a cloud-delivered security service. Do not leave this to the end, because it affects the choice of platform.

Management model

SD-WAN is only as resilient as the circuits underneath it. Plan the transport mix for each site by criticality.

Insist on diversity. Two circuits from the same provider that share a physical route or a building entrance can fail together. Where possible, use different providers and different physical paths. Hub sites and sites that terminate tunnels generally need a reachable public IP address, ideally a static one, and a broadband service behind carrier-grade address translation can cause problems. The dedicated internet access guide and the comparison of fibre, cable and wireless help with the choices, and the bandwidth requirements guide helps with sizing.

Write evaluation criteria before you speak to providers, and test them in a proof of concept.

• Application-aware routing that steers traffic by measured path quality.
• Voice and video protection, such as per-packet steering or error correction.
• Integrated or well-integrated security options.
• Direct connection to the cloud services you use.
• Zero-touch provisioning, so devices can be shipped to sites and configured remotely.
• Central management with clear visibility, reporting and an open interface for automation.
• High availability options at larger sites.
• A licensing model you understand, including what happens to features if a licence lapses.
• Support for the scale you will reach, in sites and throughput.

Policy is where SD-WAN delivers its value. Build it deliberately.

1. Classify applications. Group them into classes such as real-time voice and video, business-critical, general business, and bulk or recreational.
2. Mark traffic consistently. Use agreed DSCP markings on the local network so the SD-WAN device and the LAN treat each class the same way.
3. Set path preferences. Define which circuit each class prefers, and which it falls back to.
4. Define quality thresholds. Set the latency, jitter and loss levels at which a path is no longer acceptable for a class, and what happens next.
5. Plan segmentation. Keep guest, device, payment and corporate traffic in separate segments.
6. Document failure behaviour. Write down what happens when a circuit fails, when the controller is unreachable and when a device loses power.

Pick a small group of representative sites. Include an easy site, a hard site with poor circuits, and a hub or data centre. Run the pilot long enough to see typical and peak conditions.

• Test every failure case. Unplug the primary circuit during a voice call and observe the effect. Repeat for the secondary.
• Compare voice quality, cloud application response and file transfer times to the baseline.
• Confirm that security policy works as designed.
• Test the management tools and the alerts that your operations team will rely on.
• Write the rollback procedure and rehearse it.

1. Pre-stage and label devices, and confirm circuits are active before the installation date.
2. Schedule each cutover in a maintenance window, with on-site or remote help available.
3. Run the new path alongside the old one where possible, then switch traffic.
4. Verify against a checklist covering circuits, tunnels, voice, key applications and security.
5. Keep the old circuits live until the new design has proven stable, and cancel them only after that.
6. Review each wave and adjust the plan.

After rollout, monitor continuously and review policies against real data. Track circuit performance and the outages for each provider, hold them to their service commitments using what the SLA guide describes, and review contracts before renewal. Use change control for policy edits, because one rule can affect every site.

• Skipping application discovery and guessing at policy.
• Buying circuits that share a failure point and calling it redundancy.
• Leaving security design to the end.
• Neglecting quality settings on the local network, so voice markings are lost before they reach the SD-WAN device.
• Failing to test failover until a real outage happens.
• Cancelling existing circuits before the new design is proven.
• Undersizing hub sites, which become a bottleneck for every branch.

• Who owns the devices and the configuration, and what happens to both if we leave?
• How quickly do you make policy changes, and how are they approved and tested?
• How do you prove circuit diversity, and who coordinates repairs across carriers?
• What is monitored, by whom, and what response times apply?
• What happens to the service if the central controller is unreachable?
• Which security functions are included, and which cost extra?
• How do you handle sites where no good wired circuit exists?

How long does an SD-WAN deployment take?

It depends on the number of sites and on circuit lead times. Circuit orders are often the slowest part, so start them early. Planning and the pilot often take longer than teams expect, and they pay off in a smoother rollout.

Do we need to replace our MPLS circuits?

Not necessarily. SD-WAN can run over MPLS as one of several transports. Many organizations keep MPLS at selected sites or for selected traffic during and after the transition.

Can SD-WAN work over cheap broadband?

It can improve how traffic uses broadband, but it cannot guarantee performance over a best-effort service. Use it with an appropriate mix, and put critical sites on circuits with service commitments.

What skills does the team need?

Routing, security and application knowledge, plus comfort with central management tools. If your team lacks these or round-the-clock coverage, a co-managed or fully managed model may fit better.