The core switch is end-of-life, or it is a single box holding the whole site together, and it has to be replaced. Everything routes through it, every VLAN’s gateway lives on it, and it cannot simply be unplugged and swapped. The way to replace a core without downtime is to never actually turn it off until nothing depends on it — bring the new one up beside it, pair them, move the traffic across link by link, and only then retire the old.
A core is the one box you cannot casually reboot: it holds every VLAN’s gateway and every inter-VLAN and WAN path. Replacing it by unplugging the old and cabling the new is a planned outage measured in hours if it goes well, and a disaster if a config detail was missed. Neither is acceptable for most sites.
The surgical replacement keeps the old core running the whole time. You rack the new core beside it, give it the config and a routing adjacency so both can forward, make the gateway a virtual address (FHRP) that can live on either, then move access-switch uplinks and the active gateway across one at a time. If anything misbehaves, that one link or that one gateway flips back. The old core is powered off only when it is demonstrably carrying nothing.
01
The new core runs in parallel with the old, sharing a virtual gateway, while uplinks move across one by one. The old is retired only when idle.
02
Parallel, pair, migrate, flip the gateway, decommission — and the virtual gateway means hosts never notice the move.
| Step | Do | Rollback |
|---|---|---|
| 1 · Stage the new core | Rack and cable it, load the config, but leave its access uplinks shut. Verify it off to the side. | Leave shut / unrack. |
| 2 · Make the gateway virtual | Convert each VLAN gateway to an FHRP virtual IP on the old core (hosts now point at the virtual, same IP). | Revert to the plain SVI. |
| 3 · Pair the cores | Bring up FHRP between old (active) and new (standby), and a routing adjacency / shared trunk between them. | Remove the new core from the FHRP group. |
| 4 · Migrate uplinks | Dual-home each access switch to both cores, then move its primary one at a time. STP/bond keeps a path throughout. | Move the uplink back to the old core. |
| 5 · Flip the active gateway | Raise the new core’s FHRP priority so it becomes active for each VLAN. Sub-second, no IP change. | Lower priority — old core resumes active. |
| 6 · Decommission | Confirm the old core carries no traffic and is not active for any group, then power it off. | Power on + re-raise priority (kept in export). |
Two traps. First, if hosts point at the core’s real MAC rather than an FHRP virtual MAC, moving the gateway changes the MAC and strands ARP caches until they age out — convert to FHRP (step 2) before the swap so the gateway IP and MAC are portable. Second, decide the spanning-tree root deliberately: during the parallel phase the new core should take over as root in a controlled step, not win or lose an election by surprise and reconverge the whole campus. Set bridge priorities explicitly.
03
| Before you start | Why |
|---|---|
| Config parity old → new, reviewed | The new core must match VLANs, routing, ACLs, services — drift here is the outage. |
| Gateways already virtual (FHRP) | Makes the gateway IP and MAC portable so the flip is invisible. |
| STP root priorities set explicitly | No surprise re-election when the second core appears. |
| Dual-home before you move | Every access switch has a path to both cores before any primary moves. |
| Prove the old core idle before power-off | No active FHRP groups, no traffic — then retire it. |
Takeaways
A core swap is low-drama when the new box runs beside the old and traffic moves across gradually. I parallel the cores, migrate uplinks and gateways one at a time, and retire the old one only when it is carrying nothing.
Book a Discovery Call →