Network hardware bundles smart-licensing subscriptions with premium switches/routers and costly support renewals. Cisco stacks DNA and smart-licensing on top of the hardware with SmartNet renewals, Juniper bills feature licenses and support separately (with added roadmap uncertainty for some buyers after the HPE acquisition), and Arista carries EOS subscription and support costs. Open network operating systems, SONiC, VyOS, FRRouting, run on whitebox/commodity (or existing Broadcom-based) hardware and break the per-device licensing model. Networking migrations are the most change-sensitive in this catalog, so they’re staged and lab-validated, never cut over all at once.
Pick the target by role
The two open NOSes solve different problems, so scope the target to the job before anything else. SONiC is a data-center switch NOS for whitebox/Broadcom-ASIC leaf/spine fabrics: it uses config_db.json (Redis) plus FRR for routing and is strong for BGP/EVPN underlay-and-overlay designs. VyOS is a Linux-based software router with a set-style CLI, suited to routing, edge, WAN, firewall, NAT, and VPN roles on x86 or supported platforms. Send fabric switching to SONiC and routing/edge to VyOS; do not try to make VyOS a top-of-rack switch or SONiC an edge router. FRRouting underpins the routing stack in both and is an option where you need open routing on Linux directly.
Validate hardware first
The gating question is hardware support: confirm the switch ASIC is on the target NOS’s Hardware Compatibility List before anything else. Inventory devices, configs, VLANs, routing (BGP/OSPF/EVPN), and ACLs, and map the fabric topology and uplinks.
Stage in a lab
Convert device configs to the target NOS format (e.g. SONiC’s config_db.json, VyOS set-style config) and validate on a non-production pod: bring up routing, verify telemetry/SNMP, and compare against the vendor baseline. There is no automatic converter, so rebuild feature by feature from the intended design rather than pasting the old IOS, Junos, or EOS text. Mirror your real addressing and advertise into a test context so you can diff route tables in both directions against the live device. Prepare rollback configs and ensure out-of-band (OOB) access to every device, and rehearse the fail-back so it is a proven procedure, not an improvisation during a change window.
Migrate pod-by-pod
Cut over the fabric incrementally during change windows, leaf/spine pod by pod, verifying routing/STP/LACP and end-to-end reachability after each device before proceeding. Keep the saved vendor config ready so rollback via OOB is immediate.
Proving routing converges under failure
Link/throughput and uplink/MLAG failover tests, routing-convergence and ACL verification, telemetry/streaming validation, and a soak test under production-like load. The acceptance bar is “routing converges and traffic flows correctly under failure.”
Why “go slow” is the whole strategy
Never cut the whole fabric at once. Validate on the lab pod, then a non-critical production pod, and keep OOB + rollback configs at every step. A storage or app migration that goes wrong affects one workload; a fabric migration that goes wrong can take down everything behind it, so “go slow” is the strategy, not a caveat. Where the target NOS interoperates on the wire with the outgoing vendor, such as EVPN Type-2 and Type-5 routes between SONiC and remaining Arista nodes, a phased overlay lets old and new coexist while you migrate switch by switch.
Weigh the operational cost, not just the license
Open NOSes remove per-device licensing, but you take on the operations the vendor used to run: observability, automation, and support you assemble yourself (from gNMI, Prometheus, FRR, and your own tooling on SONiC, or scripting, Ansible, and an LTS subscription on VyOS). That is a real cost and belongs in the comparison. For small teams or fabrics that lean on niche vendor features, the day-two operations can outweigh the license savings, so decide with eyes open.
Use the TCO calculator to model a per-device comparison.