The Case for Rethinking VeloCloud Migrations
VeloCloud customers have weathered a remarkable amount of turbulence. The platform was acquired by VMware in 2017, VMware spun off from Dell EMC in 2021, and then Broadcom completed its acquisition of VMware in 2023. Along the way, the product has been branded as Velo, Velo SD-WAN, VeloCloud SD-WAN, VMware SD-WAN by VeloCloud, and VMware NSX SD-WAN by VeloCloud — a list that is itself incomplete. Just last year, VMware announced yet another renaming, to VMware VeloCloud SD-WAN and VMware VeloCloud SASE, secured by Symantec.
Behind the naming churn lies a deeper concern: frequent reorganizations of networking and security products into different business units signal shifting strategic priorities. As Broadcom pursues a single vendor SASE strategy, customers are left wondering where their deployed infrastructure fits.
For those considering a transition, the path forward requires examining what's fundamentally wrong with the architecture-by-acquisition approach, understanding what a migration entails, and knowing what resources exist to help.
Architecture, Not Acronyms
Single vendor SASE is frequently treated as a feature checklist exercise. Collect enough product acronyms — ZTNA, SD-WAN, SWG, CASB, DLP, FWaaS — and the assumption is that the requirements have been met. But acquiring a stack of features from different vendors often produces something as convoluted as the technology it was meant to replace.
A clear warning sign is combining an SSE platform designed by one vendor with SD-WAN from another. The conceptual model for SASE shows two halves: cloud-delivered networking and cloud-delivered security. It seems logical that joining a VeloCloud SD-WAN implementation with a Symantec SSE offering would complete the picture. In practice, these worlds don't merge cleanly. SD-WAN is built for site-to-site connectivity over the SD-WAN fabric, while SSE enforces policy for user-to-application traffic from remote users or for traffic leaving that fabric. Bridging them means accepting security inconsistencies, proxy chains that add latency, or pushing security enforcement to the edge instead of delivering it from the cloud.
Connectivity as a Foundation
Cloudflare's approach to single vendor SASE starts from its global network, built with private data centers, overprovisioned capacity, and a private backbone. The network is designed for any-to-any connectivity — passing traffic to any destination — rather than treating the public cloud as a SASE delivery point. Public cloud infrastructure is optimized as a destination for traffic, not for transit. By controlling data center and network design directly, Cloudflare delivers both networking and security services from the same foundation.
This relies on composability: the underlying connection between a customer site and a Cloudflare data center stays the same regardless of use case. Adding functionality requires no downtime for service insertion. The connection remains constant; only the services and destinations change as usage expands. For branch connectivity, Magic WAN handles traffic regardless of direction — inbound, outbound, or east-west — by on-ramping everything through one of Cloudflare's 310+ anycasted data centers for consistent policy enforcement. Full compute capabilities at every data center eliminate the need to forward traffic elsewhere. The model is light edge, heavy cloud, with services running inside the Cloudflare connectivity cloud rather than on premises.
Planning the Move
A migration starts with a consultation with Cloudflare's solutions architecture team. These architects specialize in network modernization and can map SASE goals into a series of smaller, executable projects, drawing on experience from hundreds of similar transitions.
For product education, Cloudflare offers workshops on Magic WAN covering its architecture and rollout approach. Magic WAN supports multiple network insertion models — a tunnel from an existing device, the turnkey Magic WAN Connector, or a virtual appliance — so migration can proceed in parallel with existing infrastructure or as a phased replacement. Cloudflare's specialist teams can help offset transitionary hardware and license costs as VeloCloud is phased out.
Technical resources include reference architectures and quick start guides tailored to different connectivity goals: reducing on-prem network footprint in favor of what's sometimes called "coffee shop networking," retiring legacy SD-WAN, or replacing conventional MPLS entirely. Cloudflare's customer success teams offer migration services designed specifically for Magic WAN transitions of varying scale.
