UK SD‑WAN migration: pilot criteria plus Re‑Solution pricing

The fastest route to SD-WAN is a phased migration: assess every site and contract, run a two to three-site pilot against a documented performance baseline, then roll out in waves while MPLS stays live as a fallback. Start this week by inventorying sites, circuits and contract expiry dates, and shortlisting your pilot locations. Expect the full transition to run several months to over a year depending on site count, with contract lock-in and application performance regressions as the two risks that derail more projects than any technical failure.

TL;DR:

Conduct a thorough site inventory, including circuit details, contract end dates, and application criticality, to prevent budget overruns and optimize wave planning.

Log baseline network metrics such as latency, jitter, packet loss, and throughput over at least two business cycles to set realistic go/no-go thresholds for migration success.

Deploy SD-WAN using a phased approach with pilot sites that represent typical branch profiles, ensuring acceptance criteria are established before cutover and fallback options remain available.

Implement zero-touch provisioning and detailed pre-staging to minimize configuration errors, with clear rollback criteria defined prior to each site migration.

Maintain continuous post-migration monitoring, application-aware routing adjustments, and staff training to ensure lasting performance improvements and operational readiness.

Re-solution

Plan Your Network Migration With Confidence

Re-Solution provides infrastructure audits, network surveys, NaaS and managed IT services for organisations planning robust connectivity.

Explore Re-Solution

Assess your starting point: inventory and business objectives
How do you establish an SD-WAN performance baseline?
Design your SD-WAN architecture and coexistence strategy
Create the detailed migration plan and wave schedule
Onboarding and provisioning: templates, ZTP/PnP and pre-staging
Execute site migration and cutover with parallel runs and rollback criteria
Post-migration validation, tuning and application-aware routing
Day-2 operations: continuous monitoring, patching and optimisation
Risk management and mitigation strategies during migration
Change management and communication plan with stakeholders
Training and enablement for network operations teams
Compliance and security considerations specific to SD-WAN migration
Author perspective: the assessment shortcut that costs more later
How Re-Solution can help: assessment, NaaS and managed SD-WAN
Sources
FAQ

Assess your starting point: inventory and business objectives

An SD-WAN migration plan is only as reliable as the inventory behind it. Before anyone discusses topology or vendors, you need a site-by-site record of what exists today and why it matters to the business.

Build a register that captures circuit type, bandwidth, monthly cost, contract end date, and the applications running at each site. Cross-reference this against your MPLS billing to catch shadow circuits that nobody remembers ordering. Migration playbooks consistently flag contract expiry misalignment as the single biggest cause of budget overruns, because early termination penalties on MPLS contracts can wipe out a year’s projected savings.

Once the inventory is solid, classify applications by criticality rather than by department. A voice system and a print server both sit in “operations,” but they need very different treatment during cutover.

Fields to capture per site:

Circuit type, provider, bandwidth and monthly cost
Contract start date, end date, and early termination clause
Applications hosted or consumed, tagged by criticality (critical, important, best-effort)
Site headcount, physical access constraints, and existing hardware refresh cycle

Translate business objectives into numbers you can act on. Group sites into waves based on shared contract expiry windows, similar risk profiles, and geographic proximity, since this makes procurement and field logistics considerably easier to schedule.

How do you establish an SD-WAN performance baseline?

You establish a baseline by logging latency, jitter, packet loss, and throughput on the existing MPLS network for at least two to four weeks before touching anything, broken down per site and per application. Without this, you have no defensible way to prove the migration worked, and no way to set sensible go/no-go thresholds for the pilot.

Capture these metrics as a minimum:

Round-trip latency (ms) between each branch and the data centre or cloud edge
Jitter (ms), particularly for voice and video traffic
Packet loss (%) under normal and peak load
Throughput (Mbps) achieved versus contracted bandwidth
Mean Opinion Score (MOS) for any VoIP traffic

Use active probing tools that generate synthetic traffic on a schedule, rather than relying solely on passive SNMP polling, since synthetic tests catch intermittent degradation that averages hide. Log results per site and per critical application so you can compare like for like once SD-WAN is live.

Pro Tip: Run your baseline capture across at least one full business cycle, including month-end reporting or peak trading periods, so you’re not comparing SD-WAN performance against an artificially quiet MPLS week.

For go/no-go thresholds, a common benchmark is requiring the pilot’s broadband-based paths to match or beat MPLS latency on critical applications, with packet loss held under 1%. If a pilot site misses that mark after tuning, you delay its wave rather than force the cutover.

Design your SD-WAN architecture and coexistence strategy

Your topology choice determines how resilient and how complex the network becomes, so this decision needs to happen before procurement, not during it.

Hub-and-spoke routes branch traffic through a central data centre or cloud hub, which suits organisations with centralised applications and simpler security policy needs. Regional hub designs add secondary hubs closer to clusters of branches, cutting latency for geographically spread estates without the full complexity of mesh. Full mesh connects sites directly to each other, which pays off when branch-to-branch traffic (site-to-site file transfer, VoIP between offices) is heavy enough to justify the extra control-plane complexity.

Coexistence with MPLS during the transition matters as much as the end-state design. Cisco’s design guidance recommends deploying SD-WAN controllers and migrating the data centre before touching branch sites, so branches always have a stable hub to connect into once their turn comes.

Key coexistence and security decisions:

Keep MPLS as a transport option inside the SD-WAN overlay during transition, rather than ripping it out immediately
Route SaaS traffic via direct internet breakout at the branch rather than backhauling through the data centre, which cuts added latency from tens of milliseconds to a few
Apply segmentation and zero-trust access controls at the SD-WAN edge rather than bolting security on afterwards, aligning with zero-trust architecture principles
Build redundancy with a broadband primary and LTE or 5G secondary at sites where a single physical circuit is a single point of failure

Sites with strict uptime requirements deserve a dedicated look at failover design before you finalise the wave plan, particularly around how quickly the secondary path activates and whether that switchover is genuinely seamless for voice traffic.

Create the detailed migration plan and wave schedule

A workable sd-wan implementation strategy hinges on sequencing, not ambition. Trying to migrate 40 sites simultaneously is how projects stall for months over a single unresolved circuit order.

Select two to three pilot sites that represent your typical branch profile but carry low business risk if something goes wrong. Avoid your busiest or most compliance-sensitive location for the pilot.
Define acceptance criteria before you start, not during. This should reference your baseline KPIs directly: latency, jitter, packet loss and application response times that the pilot must match or beat.
Group remaining sites into waves of ten to twenty, aligned to contract expiry dates, geographic clusters, and shared risk profile, following the pragmatic wave sizing that reduces rollout risk.
Order circuits and hardware eight to twelve weeks ahead of each wave. Broadband installation lead times vary wildly by region and provider, so build in a buffer rather than assuming a fixed date.
Build a pre-staging checklist per site: confirm physical access, power, rack space, and a named on-site contact before shipping any hardware.
Draft a stakeholder communication plan for each wave, covering what changes, when, and who to contact if something breaks.

Manufacturing and logistics sites often carry additional constraints, such as shift patterns that limit maintenance windows or shop-floor equipment that cannot tolerate any downtime; a manufacturing-specific SD-WAN approach is worth reviewing if that describes your estate. If your migration coincides with a physical office or data centre move, coordinating the two projects properly, as covered in guidance on relocating offices without business downtime, prevents two disruptive projects colliding on the same weekend.

Onboarding and provisioning: templates, ZTP/PnP and pre-staging

Manual configuration is where SD-WAN rollouts lose days to typos and mismatched serial numbers. Zero-touch provisioning (ZTP) and Plug-and-Play (PnP) let a device phone home to the controller and pull its configuration automatically once it is physically connected, which is why Cisco’s design guidance treats ZTP/PnP as standard practice for branch rollouts rather than an optional extra.

ZTP/PnP works well for standard branch deployments where hardware is known in advance. Reserve manual bootstrap for edge cases: sites with unusual network topology, or where controller connectivity cannot be guaranteed on day one.

Your device and policy templates need, at minimum:

System IP and site ID, unique per device
Organisation name and controller reachability information
Validator (vBond) address so the device can authenticate onto the fabric
Policy templates pre-mapped to the site’s application criticality tier

Before shipping anything, run each template through a lab test with a spare device to catch errors before they reach a live site. On the logistics side, confirm serial numbers are registered with your smart account well ahead of shipping, and give field technicians a one-page checklist covering power, cabling, and who to call if the device fails to phone home.

Execute site migration and cutover with parallel runs and rollback criteria

Cutover day should follow the same sequence every time, so nothing depends on memory.

Run prechecks: confirm the SD-WAN device is provisioned, reachable, and passing health checks before touching production traffic.
Switch traffic to the SD-WAN path for a defined test window, starting with non-critical applications if your design allows staged cutover within a site.
Validate immediately against baseline KPIs: latency, jitter, packet loss and, for voice, MOS scores.
Run a parallel period with MPLS still active as fallback, typically one to two weeks, comparing SD-WAN and MPLS performance side by side on the same applications.
Confirm go/no-go against your pre-agreed thresholds before decommissioning the MPLS circuit at that site.

Public migration playbooks recommend defining go/no-go criteria and keeping MPLS live during the parallel run, because reversing a premature circuit cancellation is far harder than extending a parallel run by another week.

Pro Tip: Set your rollback trigger as a specific, written number before cutover day, such as “packet loss above 2% for more than 15 minutes.” Deciding rollback criteria in the moment, under pressure, almost always leads to teams pushing through problems they should have reversed.

Common failure modes include misrouted policy templates sending critical traffic down the wrong path, LTE failover not activating correctly under real load, and DNS or proxy configurations that were never updated for the new breakout model. Catching these in the pilot, where the acceptable blast radius is small, is the entire point of running one.

Post-migration validation, tuning and application-aware routing

Cutover is not completion. The migration only counts as successful once you can demonstrate, against the baseline you captured earlier, that applications perform as well or better.

Run your validation checklist against every KPI logged during the baseline phase: latency, jitter, packet loss, throughput and MOS, per site and per critical application. Any metric that regressed needs investigation before you close out that site’s migration.

Tuning application-aware routing is where SD-WAN starts earning its keep. Map QoS policies to actual application behaviour rather than generic categories: voice and video need low-latency paths guaranteed, bulk file transfer can tolerate a slower link, and SaaS traffic should be breaking out locally rather than routing via a central hub.

Key post-migration actions:

Compare every site’s live KPIs against its own MPLS baseline, not a generic target
Adjust QoS and path-selection policies for applications showing latency or jitter regressions
Use path analytics to spot underperforming ISPs early, before they become a support ticket backlog
Update network runbooks and hand documented procedures to the operations team

Analysis of large-scale SD-WAN deployments shows continued enterprise momentum behind this application-aware model, largely because centralised MPLS routing simply cannot replicate the granular, per-application control SD-WAN policy engines offer.

Day-2 operations: continuous monitoring, patching and optimisation

SD-WAN benefits erode quickly without disciplined ongoing operations. Define clear ownership from day one: network operations owns monitoring and incident response, security owns policy review, and a named engineering lead owns software lifecycle decisions.

Priorities for sustained performance:

Set alert thresholds tied to your original baseline KPIs, not arbitrary defaults, so alerts reflect genuine degradation
Establish a software upgrade and patching cadence, typically quarterly for controllers, with emergency patching processes defined separately
Review application policies every quarter as business needs shift and new SaaS platforms get adopted
Run capacity planning reviews twice yearly, checking whether branch bandwidth still matches actual usage growth

Case studies from organisations that have completed dozens of these migrations point to operational readiness, not technical rollout, as the factor that most often separates a migration that delivers lasting gains from one that quietly regresses within a year.

Risk management and mitigation strategies during migration

Every SD-WAN migration plan carries risk categories that recur regardless of company size: contractual, technical, and organisational.

Contractual risk centres on MPLS termination penalties and circuit lead-time uncertainty. Mitigate it by ordering broadband circuits well ahead of contract expiry and negotiating month-to-month extensions on MPLS where full termination isn’t yet possible.

Technical risk shows up as application performance regressions, misconfigured policies, or failover paths that don’t activate correctly under real load. The pilot exists precisely to surface these issues while the blast radius is small; resist any pressure to skip or shorten it to hit an arbitrary deadline.

Organisational risk is subtler and harder to spot in a project plan. It includes operations staff who haven’t been trained on the new policy-based model, stakeholders who weren’t told about a maintenance window, or a vendor relationship that assumed more support than was actually contracted. A documented rollback plan, agreed before cutover rather than improvised during it, is the single most effective control against all three categories combining into an outage that could have been contained.

Build a simple risk register at project kickoff, ranking each identified risk by likelihood and business impact, and revisit it before every wave rather than only at project start. Risks change as you learn from earlier waves; a threat that seemed unlikely in wave one can become a certainty by wave four if nobody updates the register.

Change management and communication plan with stakeholders

SD-WAN migration fails politically more often than it fails technically. Executive alignment needs to happen before the first circuit is ordered, not after the first outage.

Identify an executive sponsor who can make trade-off decisions quickly, such as approving a delayed cutover or an unbudgeted LTE failover unit, without a lengthy sign-off chain. Pair that sponsor with an operational owner, typically the network manager, who runs the day-to-day plan and reports progress against the wave schedule.

Communication needs to reach three distinct audiences with different information. Executives want risk status and budget tracking. Site-level stakeholders, such as branch managers or factory floor supervisors, need practical detail: what date, how long the disruption lasts, and who to call if something breaks. IT operations staff need the technical detail: what’s changing in the network path, what monitoring will flag, and what their role is during the cutover window.

A simple cadence works well in practice: a weekly status update to the executive sponsor throughout active migration, a two-week-ahead notice to each site before its wave begins, and a same-day confirmation once a site’s cutover completes successfully. Skipping the site-level notice is a common mistake, and it’s usually what generates confused support tickets on cutover day rather than any technical fault.

Training and enablement for network operations teams

SD-WAN shifts network operations from manual, box-by-box configuration to policy-driven management through a central controller. That’s a genuine skills shift, not just a new interface to learn.

Operations teams need hands-on familiarity with the SD-WAN controller dashboard before the first live site cuts over, ideally practising against the pilot sites while the stakes are still low. Cover policy creation and troubleshooting specifically: how to read path analytics, how to adjust application-aware routing rules, and how to interpret alerts tied to the baseline KPIs established earlier.

Build a runbook library covering the most common operational tasks: adding a new site to an existing wave template, adjusting QoS for a newly onboarded application, and diagnosing a failover event. Runbooks written during the pilot, while the process is still fresh, tend to be far more useful than ones written retrospectively once the project has moved on to the next wave.

Lessons from organisations further along in their SD-WAN journeys consistently point to training gaps, rather than technology gaps, as the reason some migrations deliver a strong cutover but a disappointing year two. Budget time for this training as a distinct project task, not an assumed side effect of the rollout.

Compliance and security considerations specific to SD-WAN migration

SD-WAN changes your network’s security perimeter, and that shift has direct compliance implications, particularly once branch sites start breaking out to the internet locally instead of routing everything through a centrally inspected data centre.

Local internet breakout at branch sites means security inspection needs to move to the edge too, rather than assuming a central firewall still sees every packet. This is where zero-trust principles genuinely earn their place in the design: applying identity-based access controls and segmentation at the SD-WAN edge, rather than relying on network location as a proxy for trust.

Segment traffic by data sensitivity as part of the SD-WAN policy design, particularly for organisations in regulated sectors such as education or healthcare-adjacent services, where certain traffic classes may need to stay on inspected paths even after most traffic moves to direct breakout. Document these segmentation decisions clearly, because auditors will ask how sensitive data flows are protected once the network no longer routes everything through a single inspection point.

Encryption in transit should be a given across the SD-WAN fabric, but confirm your chosen platform’s default encryption standard meets your sector’s specific compliance framework rather than assuming “encrypted” is sufficient detail on its own. Review logging and audit trail capabilities too: distributed breakout points need centralised logging aggregation, or you lose visibility exactly where regulators are most likely to ask questions.

Author perspective: the assessment shortcut that costs more later

The mistake I see repeated most often is treating the baseline as a formality rather than the foundation of the whole migration risks analysis. Skip it, and you have no defensible way to prove SD-WAN improved anything, or to know when a pilot has genuinely failed versus simply looking unfamiliar. The fix is unglamorous: spend the two to four weeks properly, log everything, and treat the assessment checklist as non-negotiable groundwork, not paperwork.

— Jacob

How Re-Solution can help: assessment, NaaS and managed SD-WAN

Re-solution is the practical alternative to running this migration entirely in-house with a stretched network team. Backed by extensive Cisco partnership experience, the service includes certified consultants and componentised pricing that scales with site count, rather than a one-size-fits-all quote.

A discovery engagement typically starts with a network audit covering circuit inventory, contract mapping, and current performance baselining, delivered as a written report within a few weeks depending on estate size. From there, our professional services team can design and execute your phased migration, or if you’d rather hand ongoing operations to specialists entirely, our Network as a Service subscription covers managed SD-WAN under one predictable arrangement, with managed services support for Day-2 monitoring and patching once cutover completes. Get in touch to scope a discovery engagement for your sites.

Sources

Long-standing Cisco partners have observed that most SD-WAN migration risk sits in the assessment phase, not the cutover.

Our audit checklists cover circuit inventory, contract expiry mapping, application criticality tagging and current-state performance logging, mirrored in the network audit checklist we use with clients before any design conversation starts.

Pricing tends to scale with site count and complexity rather than a flat per-device rate, and our componentised SD-WAN pricing breakdown covers indicative budgets for estates of 3, 25, and 100 sites, useful groundwork before you approach your own board for sign-off.

FAQ

What is SD-WAN migration?

SD-WAN migration is the process of moving wide-area network traffic from traditional MPLS circuits to a software-defined overlay that manages routing centrally and can use broadband, LTE, or 5G alongside or instead of MPLS.

Is SD-WAN obsolete?

No. Market analysis shows continued strong momentum in enterprise SD-WAN adoption, and the technology is still the standard path organisations use to move away from MPLS-only architectures.

What should be in a data migration plan?

A migration plan should include a full site and circuit inventory, a performance baseline, defined pilot sites with go/no-go criteria, a wave schedule aligned to contract expiry dates, and a documented rollback procedure for each cutover.

How long does an SD-WAN migration timeline usually take?

Timelines vary by estate size, but a phased rollout with a pilot followed by waves of multiple sites typically runs several months to over a year from initial assessment to full MPLS decommission.

How much does Re-Solution charge for SD-WAN migration support?

Pricing depends on site count and scope, and current rates are detailed on the Re-Solution SD-WAN pricing page rather than published as a single flat figure.