Cisco renamed Viptela SD-WAN to Catalyst SD-WAN in 2023 — but the platform underneath continues to evolve in two divergent directions: the long-term IOS-XE Catalyst SD-WAN platform that Cisco is investing in, and the original Viptela-OS platform that is in long-term support but no longer receiving feature releases. Most existing Viptela deployments need to plan a migration path. This is what works.
Where Cisco is investing
Cisco is consolidating its SD-WAN portfolio onto a single hardware + OS combination: Catalyst 8000 Edge routers running IOS-XE, managed by vManage Cloud and the Catalyst SD-WAN Manager. The original Viptela platforms (vEdge 1000 / 2000 / 5000, ISR-equivalent Viptela models) remain in long-term support but won't see new feature releases.
For greenfield SD-WAN deployments in 2025, there's no question — Catalyst 8000 + IOS-XE is the only path Cisco is investing in. For existing Viptela estates, the question is when to migrate, not whether.
When to migrate vs. wait
If your existing Viptela deployment is meeting business requirements and you're not on a hardware refresh cycle, you can wait — Viptela LTS continues to receive security patches and bug fixes through 2027–2028 depending on platform. But "wait" needs a hard deadline: a 2027 migration becomes harder, not easier, the longer it's deferred.
Trigger events that should accelerate migration: hardware EOSL for current vEdge devices; an opportunity to consolidate WAN routing + SD-WAN onto a single Catalyst 8000 platform; a need for features only available in IOS-XE Catalyst SD-WAN (advanced AppQoE, expanded cloud connectivity, SASE integration with Cisco Secure Connect).
Migration approaches
There are three common approaches. Each works; the right choice depends on the size and risk profile of the estate.
- •Parallel-run cutover: deploy Catalyst 8000 alongside existing vEdge at every site, migrate site-by-site over a 6–12 month window. Lowest risk; highest project cost.
- •Phased datacentre-first: migrate the SD-WAN hubs first (DC + cloud gateways), then branches over a longer window. Moderate risk; requires careful design of inter-overlay routing during the transition.
- •Big-bang per-site: replace at each site in a single change window. Lowest project cost; highest individual-site risk. Works well for smaller estates (<30 sites).
The technical gotchas
Policy translation: existing Viptela centralised policy doesn't map 1:1 to IOS-XE Catalyst SD-WAN policy. Application-aware routing, security policies, control policies and data policies all need re-authoring in the new policy framework. Allow 2–4 weeks for this depending on complexity.
Authentication: Viptela ZTP onto the existing vManage doesn't bring devices into the IOS-XE controller plane. New Catalyst 8000 devices need to onboard onto the new SD-WAN Manager — typically via the Cisco Plug-and-Play (PnP) portal.
Transport tunnel re-establishment: BFD sessions, IPSec SAs, IKE associations all reset during cutover. Plan for a few minutes of branch-to-hub downtime per site during the cutover window.
Security stack integration: if you're running Cisco Umbrella, Cisco Secure Connect or third-party SASE (Zscaler ZIA, Netskope) integrated with the existing Viptela platform, the integration needs to be re-established on the IOS-XE side.
What Servnet does
We support Catalyst SD-WAN deployments across the UK enterprise market — banks, retail multisite, manufacturing groups, NHS organisations. We sell, deploy and manage Catalyst 8000 hardware + IOS-XE SD-WAN, and we run Viptela-to-Catalyst migrations as a defined practice.
A typical migration engagement runs: 1) discovery and current-state design review (2 weeks), 2) target architecture + policy re-authoring (3–4 weeks), 3) PoC pilot at 1–3 sites (3–4 weeks), 4) production migration site-by-site (size-dependent — 3 to 12 months for a typical enterprise estate), 5) Viptela controller decommission once final site is cut over.