Migrating a Mixed-Vendor Edge Without a Big Bang

Migrate in bounded, reversible waves aligned to physical and logical boundaries, not by device count.

Sequencing:

1. Inventory and dependency map: identify which plant-floor devices attach to which closets, and which closets share uplinks. Group switches into migration waves by building/line, so a wave can be isolated.
2. Pilot wave: one low-risk closet, fully migrated, with a rollback plan and a measured outage budget.
3. Wave by wave: migrate one group at a time, moving its uplinks to the target fabric and removing it from the incumbent domain. Keep waves independent so a failure in one does not affect the others.
4. Decommission last: remove incumbent switches only after their attached devices are confirmed on the target fabric and stable for an agreed soak period.

Protecting plant-floor uptime:

• Schedule each wave to a line stoppage or low-production window, even if the overall program is not a single weekend.
• Keep dual-homed paths during each wave so a single switch move does not isolate a device.
• Pre-stage configurations and test them in a lab replica of the closet.
• Define a hard rollback trigger (e.g., any device down more than the agreed seconds) and rehearse the rollback.

Governance: a wave is complete only when devices are verified connected and the wave's documentation is signed off.

Risks:

• Loop and broadcast storm: two independent spanning-tree domains joined by links can form a loop that neither domain sees in full. A misconfigured link can flood the campus.
• Inconsistent VLANs: a VLAN present in one domain but not the other causes black-holing or leaking across the boundary.
• STP root ambiguity: each domain elects its own root, and the boundary links may carry traffic in unexpected directions.
• Failure propagation: a flapping boundary link can cause reconvergence in both domains, affecting devices that are not being migrated.
• Security boundary erosion: the boundary links may bypass segmentation policy that exists inside one domain.

Management:

• Keep the number of boundary links minimal and documented, with an owner.
• Treat the boundary as a routed or explicitly controlled transit point where possible, rather than a bridged extension of both domains.
• Configure consistent VLAN allowances on the boundary links and prune everything not required.
• Set STP priorities deliberately so each domain has a clear root and the boundary does not become a transit path for either.
• Monitor the boundary links for loops, flaps, and broadcast rate, with alerts.
• Remove each boundary link as soon as the wave it serves is complete, and track remaining links as a migration risk item.

Decommission criteria:

• All attached devices are confirmed connected to the target fabric, verified by MAC/ARP tables and by device-level checks, not just by port status.
• The migrated group has run stable for an agreed soak period with no unexplained alerts.
• No remaining boundary links depend on the incumbent switch.
• Configuration and documentation are updated, and the incumbent's management system no longer holds the only copy of any configuration.
• A rollback path exists for a defined window after decommission, even if it is a cold spare.

What could go wrong:

• Hidden dependencies: a device or service that quietly relied on the incumbent switch (e.g., a management path, a DHCP relay, a legacy device) is discovered only after power-down. The dependency map and device-level verification mitigate this.
• Configuration loss: an undocumented setting on the incumbent is the only record of how something worked. Export configurations before decommission.
• Premature removal: decommissioning before the soak period ends removes the rollback path. Enforce the soak period.
• Monitoring blind spots: the incumbent may still be the only monitor for some segment. Confirm coverage before removal.

Practice: decommission in the same wave discipline as migration, with a final verification that no traffic or dependency remains.