Network Switch Migration Checklist: 7 Steps + Lab Rehearsal (2026)

Search for a network switch migration checklist and the first page is forum threads from 2020, data-center facility moving guides, and AI-generated listicles that stop at "configure the new switch." None of them fit the project you actually have — a core refresh, a vendor swap, a firewall replacement — and none of them include the one step that decides whether your maintenance window ends on time: proving the new configs behave before the window opens.

This is the checklist we use for device migrations — a Catalyst 3850 to 9300 refresh, an ASA to FortiGate swap, a Comware estate retirement all follow the same seven steps. The list first, then each step in detail.

The network switch migration checklist

Bottom line: a checklist is only as good as the evidence behind each checkbox. The rehearsal items are the ones nearly every published checklist skips — and in NetPilot, they're a prompt: the agent deploys your translated configs on a virtual mirror built from real network OS images in ~2 minutes, then runs the routing diff, STP-root check, and failover battery before your window is even scheduled.

Step 1 — Inventory and audit every switch in scope

The audit sheet is one row per switch: hostname, model, OS version, then the columns the migration lives or dies on — VLANs (defined vs. actually carrying traffic), SVIs (and which ones are a gateway for something), LAGs and port-channels (members, LACP mode), STP (mode, root and role per VLAN), ACLs (and the interfaces they're applied to), and uplinks (with what's on the far end of each).

Then audit the state the config doesn't show. MAC and ARP tables tell you what's actually plugged in; neighbor discovery (show cdp neighbors or its LLDP equivalent) finds the AP closet and the dual-homed server nobody documented. On core and distribution switches, the Layer 3 operational state is part of the audit too: routing adjacencies and the tables they produce, VRFs, route policy, and which box currently holds each first-hop gateway role — the config shows intent, but the migration has to reproduce the live state. DHCP snooping, IGMP querier placement, PoE budgets, nondefault MTUs, and the management path itself are the classic 1 AM surprises.

Firewall swaps add a security-asset inventory of their own: private keys and certificate chains, pre-shared keys (masked or vendor-encrypted in most config exports), local credentials, and license or subscription entitlements. Some of these are non-exportable by design — plan the export, reissuance, and target-import now, because a migration can pass every routing and policy check and still fail at cutover on a certificate that never left the old box. Most of these projects start from an end-of-support date — Cisco's End-of-Life listing is where many a "simple refresh" begins — and even a same-vendor generational refresh earns the full audit: a 3850 to 9300 swap looks like-for-like until the sheet surfaces the stacking layout, the uplink modules, and the licensing model change.

Step 2 — Map features from the old platform to the new

With the inventory done, map every feature in use to its equivalent on the target platform — and treat every row without a direct equivalent as a design decision, not a translation task.

How much design work this step contains depends on the migration type. A generational refresh keeps most of the syntax and moves the decisions into hardware and licensing. A cross-vendor switch swap has real protocol decisions: per-VLAN spanning tree to MSTP, HSRP to VRRP or an active-active gateway, one vendor's stacking to another's stacking or MLAG — cross-vendor CLI references like HPE's four-OS command mapping guide are worth keeping open all project. A firewall swap is the extreme case: an ASA to FortiGate migration maps an interface-ACL model onto a zone-and-policy model, and NAT ordering changes underneath — the feature map is most of the project, and a line-by-line config translation without it produces a firewall that passes the wrong traffic confidently.

The output of this step is a mapping table with a "no direct equivalent" column. Those rows are your project risk, enumerated.

Step 3 — Translate the configs, and flag what doesn't map

Converters and AI assistants draft cross-vendor translations well, and a generational refresh mostly needs a careful diff. Either way, the rule is the same: every line from the "no direct equivalent" column needs a human decision recorded next to it, and every line where the default behavior differs needs a flag — some platforms bring new interfaces up administratively down, some change L2/L3 interface defaults by product line, and a translated config can parse cleanly while forwarding nothing.

For a fully worked cross-vendor example — the complete IOS-to-AOS-CX translation table, the Comware and ProCurve variants, and the behavioral gotchas (hybrid ports, RPVST+ to MSTP instance mapping) — see our Cisco to Aruba migration walkthrough. A Comware retirement in particular hides two redesigns (hybrid ports and IRF) inside what looks like a syntax swap.

Translation gets you configs that parse. Nothing in this step proves they behave — that's the next one.

Step 4 — Rehearse in a lab: the step every checklist skips

Every published migration checklist jumps from "configure the new switch" to "schedule the cutover." That gap is where blown windows come from: the config was translated, reviewed, even peer-checked — and had never converged anywhere before it met production. This step closes the gap by deploying the translated configs on a virtual mirror of the affected segment before any hardware moves.

The agent-first version is a prompt:

"Build a mirror of the segment we're migrating: current core pair with HSRP and per-VLAN spanning tree, two access stacks on port-channels — here are the sanitized configs. Deploy the translated target configs alongside. Diff the routing tables between old and new, show me where the STP root lands on the new side, then fail an uplink under a continuous ping and report the seconds of loss."

The NetPilot agent deploys both estates on real network OS images in ~2 minutes, runs the per-vendor commands, normalizes the output, and reports the deltas. The three checks that catch most migration risk:

Diff the routing tables. Every prefix, next-hop, and metric, old side vs. new. A missing route here is a translation error caught in the lab instead of a helpdesk queue.
Verify the spanning-tree root. Per VLAN or per MST instance, confirm root landed where the design says — and list any port newly blocking.
Pull a link mid-ping. Fail an uplink, then the gateway, under continuous probes. "Fails over fine" becomes a number you can defend at the change board. Send some of those probes at the largest MTU the design carries, don't-fragment set — a lower MTU on the translated side is invisible to default-size pings and surfaces as broken storage or overlay traffic after cutover.

Migrating ACLs, or swapping a firewall? Add a fourth check: the policy matrix. Replay representative allowed and denied flows against the old and new sides — permitted traffic still passes, prohibited traffic still drops, and NAT translates the way the design says. Routing and spanning tree can agree perfectly while a translated policy permits the wrong traffic; an ASA-to-FortiGate migration isn't proven until the deny rules are. One thing no equivalence check carries: live session state. TCP flows, VPN tunnels, and NAT translations reset at a cross-vendor cutover no matter how clean the policy match — identifying the long-lived sessions and planning their drain and reconnect belongs in the cutover runbook (step 6).

The lab runs real network OS code — NetPilot supports 9+ network operating systems and growing: Nokia SR Linux, FRR, and Linux are built in; Cisco IOL, Juniper cRPD, Arista cEOS, Palo Alto, and Fortinet images come in via bring-your-own-image; and on enterprise plans any ContainerLab-compatible image, including custom vendor OSes like Aruba AOS-CX, is built into a dedicated environment for you. Direct CLI is always available too — every node takes SSH, so you can run show spanning-tree on the mirror yourself when you want to verify the agent's report by hand.

Step 5 — Parallel-run the new switch beside the old

The lab proves the config; the parallel run proves the hardware. Rack and power the new switch next to the one it replaces and move a deliberately low-risk slice first — a pilot VLAN, one port group, a closet that can tolerate a hiccup. For a firewall swap, that's a pilot subnet behind the FortiGate while the ASA carries everything else.

Stage the replacement with unique identities, though — never the translated production config as-is. Give it its own management and SVI addresses, keep it out of production FHRP groups, and leave every non-pilot SVI, adjacency, and link shut until the corresponding service actually moves. A replacement that boots the old switch's addresses and gateway identity next to the still-live original is a duplicate-gateway incident, not a pilot. Plan how the pilot reaches its gateway, though: give the pilot slice its own subnet and gateway on the replacement, or move the gateway identity for that one VLAN deliberately as part of moving the slice — the isolation rule is for everything that hasn't moved yet, and a pilot that stays bridged back to the old gateway never tests the new switch's Layer 3 forwarding or failover.

Dual-home hosts across the pair only where the design genuinely supports it — an active/standby NIC team, or a multi-chassis LAG both switches are actually members of. Two independent switches can't terminate the same LACP aggregate unless they genuinely share a multi-chassis or standards-based EVPN-multihoming design — and cross-vendor pairs outside a validated EVPN fabric almost never do; forcing it produces suspended links, MAC flapping, or a loop instead of redundancy. Where that support isn't there, move the port group cleanly rather than dual-homing it.

Then leave it running for days, not minutes, and compare against the baseline you captured in step 1: MAC and ARP learning, interface counters and errors, CPU, logs. Exercise the endpoint bootstrap path deliberately too — cold connects, DHCP renewals, 802.1X or MAB reauthentication, fresh multicast joins — because a days-long pilot can hide a broken relay or auth config behind leases and sessions that predate it. And prove the management plane end to end on the replacement: TACACS+ or RADIUS operator login, NTP sync, remote syslog, SNMP or streaming telemetry landing in monitoring — with at least one of those logins made through the dedicated out-of-band path, because the moment you need out-of-band is the moment the uplinks are down. A switch nobody can log into or see is its own outage, discovered at the worst possible time. This window is where the things a virtual lab can't test get their turn — optics and DAC compatibility, PoE, cabling, and platform hardware quirks. But a low-risk pilot proves compatibility, not capacity: it puts nothing like production-scale PoE draw, MAC and TCAM table load, or uplink throughput on the new switch. Validate those explicitly — datasheet PoE budget against the closet's measured draw, table capacities against production counts — and widen the pilot before calling the hardware proven. The lab makes this window boring; the window makes the cutover defensible.

Step 6 — Cutover night: execute a rehearsed runbook

By this step, the checklist item is not "do the cutover" — it's "the runbook has already been executed, in order, timed, against the mirror." Freeze changes ahead of the window, agree the comms plan, and run each step to a verification gate before the next begins, with an abort deadline built on a rollback duration you've actually measured — padded for the gap between virtual timing and metal, or taken from a hardware trial — rather than optimism.

The maintenance window is its own discipline — step ordering, timed convergence, failure branches, a rollback that has actually been run — and we've covered the full method in the network cutover rehearsal guide. If you rehearse only one thing from this post beyond the configs, make it the runbook.

Step 7 — Set rollback criteria before you need them

Rollback decisions made at 1 AM are made badly. Decide the triggers in daylight, and make them objective: a verification gate that fails twice, a critical service unreachable for more than a set number of minutes, convergence blowing past your threshold by a wide margin. Calibrate that timing threshold on the parallel-run hardware, or set it from the production SLA — the virtual rehearsal proves state and step ordering, but its failover timings include software forwarding and hypervisor scheduling, so they set expectations, not abort triggers. Name the person who makes the call. And because the rollback is itself a change, it only counts if it's been executed somewhere — the mirror lab from step 4 is exactly the place to run it once, timed.

After a successful cutover, resist the urge to reclaim the old switch immediately. Keep it racked and configured for 30 days — with every production-facing link shut or unplugged and access through out-of-band management only. A still-configured switch that can rejoin the network is a duplicate-IP and spanning-tree incident waiting to happen; an isolated one is a rollback asset — and it only stays one if it still matches production, so either freeze changes for the retention window or record every post-cutover VLAN, ACL, and routing change and apply them before any reconnect. The classic late failures surface on month-end batch jobs and the first full backup cycle, not on cutover night.

FAQ

What is a migration checklist?

In networking, a migration checklist is the ordered task list that moves a switch, firewall, or network segment from its current hardware or vendor to its replacement without unplanned downtime. A complete one covers seven phases: per-switch inventory and audit, feature mapping between old and new platforms, config translation, lab rehearsal of the translated configs, a parallel-run window on real hardware, the cutover itself, and pre-agreed rollback criteria. Most published checklists stop at inventory → configure → cutover — the rehearsal and rollback phases are what separate a checklist from a plan that survives the maintenance window.

What are the steps of migration?

A network switch migration has seven steps. One: inventory and audit every switch in scope — VLANs, SVIs, LAGs, STP roles, ACLs, and uplinks, per switch. Two: map every feature in use to its equivalent on the new platform and flag what has no direct match. Three: translate the configs, marking every line that needs a design decision rather than a syntax swap. Four: rehearse — deploy the translated configs on a virtual mirror lab, diff routing tables against the current network, verify the spanning-tree root, and fail links under continuous ping. Five: parallel-run the new switch beside the old on a low-risk segment. Six: cut over with a rehearsed, timed runbook. Seven: roll back against objective criteria you defined before the window opened.

What should a core switch migration plan include?

Everything the access-layer checklist includes, plus the control-plane state a core uniquely owns: where the spanning-tree root lands per VLAN or MST instance, first-hop gateway placement and failover (HSRP, VRRP, or the new platform's equivalent), every routing adjacency the core terminates, and measured — not estimated — convergence times for link and gateway failure. A core switch migration plan should also name its rollback trigger and abort deadline in advance, because a core rollback executed late is a second outage. Rehearse the core swap on a virtual mirror to prove adjacencies, root placement, and failover behavior before the window — then calibrate the timing thresholds themselves on the hardware pilot or against the production SLA.

How do you rehearse a switch migration without production hardware?

Deploy the translated configs on a virtual mirror of the affected segment, built on real network OS images so protocol behavior is executed rather than estimated. Then run three checks: diff the routing tables between the current network and the mirror, verify the spanning-tree root landed where the design says, and pull a link mid-ping to measure convergence. In NetPilot, an AI agent builds the mirror from a plain-English description or your sanitized configs in about 2 minutes and runs the validation battery for you, with SSH access to every device when you want to verify a result by hand.

Run the checklist with the rehearsal built in

Steps 1–3 are spreadsheet work. Steps 4 and 6 are where migrations are actually saved, and they're the two nobody budgets lab time for — which is exactly why they're a prompt now. Paste your sanitized configs at app.netpilot.io and ask for the mirror: current estate on one side, translated target on the other, validation battery across both.

Copy-paste ready: the vendor-migration rehearsal prompt builds a parallel-run migration lab with equivalence checks before cutover — paste it into app.netpilot.io and swap in your own platforms.

Try NetPilot Free