SDN Migrations Without Drama
How to migrate from legacy DC networks to SDN/fabric designs with validation, runbooks, and a staged cutover plan.
SDN migrations fail when teams treat them as a technology swap. The real work is building a migration system:
- standards,
- validation,
- operational readiness,
- controlled waves.
Step 1: Baseline the current world
Before you migrate anything:
- map critical dependencies (east-west + north-south),
- capture “known-good” routing/adjacency state,
- identify blast-radius boundaries,
- list the top recurring incidents and why they happen.
You can’t prove improvement without a baseline.
Step 2: Define the target pattern (and keep it small)
Pick a fabric pattern and standardize it:
- underlay standards,
- overlay/segmentation approach,
- routing boundaries,
- failure domains.
Avoid “feature tours.” Choose the smallest set that meets requirements and is easy to operate.
Step 3: Build validation into every change
Every migration wave needs deterministic checks:
- reachability tests for key paths,
- adjacency sanity (BGP/OSPF/EVPN control plane where applicable),
- policy verification (ACL/firewall/WAF dependencies),
- baseline diffs to detect drift.
Automation beats hero troubleshooting.
Step 4: Migrate by domain, not by device
Successful programs migrate by application domains:
- pick one low-risk domain first,
- move its dependencies as a unit,
- validate end-to-end,
- scale the wave size only after success.
Step 5: Operationalize the new world
New architecture needs new operations:
- dashboards aligned to failure modes,
- incident runbooks,
- on-call handover docs,
- change methods and rollback criteria.
Closing thought
SDN isn’t the goal. Operable, repeatable, safe change is the goal. SDN is just one way to get there when it reduces complexity and improves validation.