SDN Migrations Without Drama: A Practical Guide from ACI to NSX and Beyond

SDN migrations fail when teams treat them as a product replacement.

ACI to NSX is not just "Cisco to VMware." NSX to another platform is not just "VMware to something better." In both cases, the real work is moving policies, dependencies, routing, operations, and ownership without breaking the business.

This guide keeps the migration practical.

First decide why you are moving

Do not start with the target product. Start with the reason.

Common reasons include:

the current platform is too complex to operate
licensing or support has become difficult
cloud and Kubernetes requirements have changed
network and security policies are hard to validate
automation is weak or too vendor-specific
troubleshooting takes too long during incidents

If the migration does not solve an operating problem, it becomes another expensive platform swap.

Track 1: Cisco ACI to VMware NSX

ACI and NSX solve overlapping problems, but they do not think the same way.

ACI is commonly built around fabric constructs, bridge domains, endpoint groups, contracts, and external L3Out connectivity. NSX is commonly built around logical segments, distributed routing, gateway firewalls, distributed firewall rules, Tier-0/Tier-1 routing, and integration with virtualization or cloud operating models.

The migration must translate intent, not copy configuration line by line.

Step 1: Map ACI constructs to NSX intent

Build a simple translation table before touching production.

ACI area	What to capture	NSX target question
Tenant	application and ownership boundary	does this become a project, domain, or environment boundary?
VRF	routing and segmentation boundary	does this map to a Tier-0/Tier-1 design or separate routing domain?
Bridge domain	subnet and gateway behavior	does this become an NSX segment and gateway interface?
EPG	workload grouping	does this become a security group, segment, tag, or policy group?
Contract	allowed traffic intent	does this become distributed firewall or gateway firewall policy?
L3Out	external routing	how will north-south routing, BGP, firewalls, and load balancers connect?

Do not migrate every ACI object as a separate NSX object. That usually carries old complexity into the new platform.

Step 2: Clean policy before migration

ACI environments often contain contracts, filters, EPGs, and temporary exceptions that no longer reflect the application.

Before migration:

remove unused EPGs and contracts
identify broad "allow any" rules
confirm which flows are still required
separate application flows from infrastructure flows
document exceptions with owners and expiry dates

Policy cleanup is easier before the move than after a failed cutover.

Step 3: Build NSX beside ACI

Avoid replacing the fabric in one move.

A safer pattern is:

deploy NSX in parallel
connect NSX north-south routing to the existing network
keep firewalls and shared services reachable from both sides
migrate one application domain first
validate application traffic before increasing wave size

The goal is not to prove NSX works in a lab. The goal is to prove a real application can run through the new design safely.

Step 4: Migrate by application domain

Do not move by VLAN, subnet, leaf switch, or rack unless that matches the application boundary.

For each domain:

list workloads, subnets, VIPs, firewalls, DNS records, and service dependencies
capture current routing, latency, packet loss, and allowed flows
build the NSX segment, routing, and firewall policy
test east-west, north-south, backup, monitoring, and admin access
move traffic during a controlled window
compare post-move behavior with the baseline

If one domain cannot be validated cleanly, the next wave should not start.

Track 2: VMware NSX to a better-fit platform

"Better" depends on the business problem. It may mean lower cost, simpler operations, stronger cloud alignment, better automation, or less vendor lock-in.

Do not choose a replacement because it is popular. Choose it because it fits the environment you actually need to run.

Common target patterns include:

EVPN/VXLAN fabric with open standards and strong operational control
cloud-native networking for public cloud-heavy estates
Kubernetes-focused networking for platform engineering teams
managed network services when the team wants less infrastructure ownership
security-first segmentation platforms when microsegmentation is the main requirement

The right answer may be a product. It may also be a simpler architecture.

Step 1: Decide what NSX is doing today

Before replacing NSX, separate its responsibilities.

Capture whether NSX currently provides:

logical switching
distributed routing
north-south routing
distributed firewall
load balancing
VPN
Kubernetes networking
automation workflows
disaster recovery networking
cloud extension

Many migrations fail because teams replace one NSX feature and forget the supporting features around it.

Step 2: Choose the target by capability, not brand

Use a decision matrix.

Requirement	Good target direction
simple datacenter fabric	EVPN/VXLAN with clear routing and operations
strong VMware dependency remains	keep NSX for the VMware estate and simplify around it
public cloud is the main platform	native cloud networking with centralized policy and observability
Kubernetes is the main platform	CNI, service mesh, ingress, and network policy built for platform teams
microsegmentation is the main driver	security policy platform with strong discovery and flow validation
small team, limited operations capacity	managed service or simpler routed design

The mistake is replacing NSX with another complex platform when the real requirement is a simpler operating model.

Step 3: Extract policy and dependency data

Before moving away from NSX:

export firewall rules and groups
identify dynamic groups, tags, and naming patterns
map Tier-0 and Tier-1 routing
list NAT, VPN, load balancer, and edge dependencies
collect flow data from monitoring tools
identify rules with no recent hits

Then rationalize the policy.

Do not copy every distributed firewall rule into the new world. Keep required intent, remove stale rules, and document exceptions.

Step 4: Plan coexistence

Most NSX exits need a coexistence phase.

Plan how the old and new worlds will share:

routing
DNS
firewall paths
load balancers
monitoring
backup and recovery traffic
admin access
IP address management

If coexistence is unclear, rollback will be unclear too.

Common migration checklist

Use this checklist for both tracks.

Before migration

define the business reason for the move
identify application owners and service owners
baseline routing, policy, latency, packet loss, and critical flows
document dependencies on DNS, AD, NTP, monitoring, backup, firewalls, and load balancers
classify applications by risk and complexity
choose the first low-risk migration domain
define rollback criteria before the cutover

During migration

keep the first wave small
validate routing before application testing
validate policy before switching real traffic
test from the user side and the application side
keep command outputs, screenshots, and test results as evidence
stop if validation fails instead of pushing through the window

After migration

compare the new behavior with the baseline
review incidents, delays, and exceptions
update diagrams, runbooks, and monitoring
train operations on the new failure modes
increase wave size only after repeated clean migrations

Validation tests that matter

A migration is not complete because the workload moved. It is complete when the workload is proven.

Minimum validation should include:

default gateway reachability
routing adjacency and route table checks
east-west application flows
north-south user and internet flows
firewall rule hit counts
DNS resolution
load balancer health
backup and monitoring traffic
latency and packet loss comparison
failover or rollback test for the first wave

Automate these checks where possible. Manual checks are acceptable for early waves, but they must be repeatable.

Simple cutover model

A practical cutover model looks like this:

Freeze policy changes for the selected domain.
Capture the current baseline.
Build the target network and policy.
Test without production traffic where possible.
Move one application or service group.
Validate end to end.
Keep rollback available until the service is stable.
Record lessons before the next wave.

This is slower than a big-bang migration, but it is much safer.

What to avoid

Avoid these patterns:

choosing the target platform before defining the operating problem
copying old policy mistakes into the new platform
migrating by device instead of application domain
treating distributed firewall rules as documentation
skipping rollback because the new platform is already built
calling the migration complete before operations can support it

The new platform must be easier to run, not just newer.

Closing thought

ACI to NSX, NSX to EVPN, NSX to cloud-native networking, or NSX to another platform all have the same hard part: proving that applications, policy, routing, and operations still work.

The safest SDN migrations are simple, staged, validated, and owned by operations from the start.