Removing a switch or router from a production network is not simply a hardware task. A device can appear lightly used while still carrying a spanning-tree path, first-hop gateway, routing adjacency, management service, port-channel member, EVPN/VXLAN function or the only surviving path for a critical system.
Core principle: do not use “no obvious traffic” as evidence that a switch or router is safe to remove. Validate topology, control-plane state, redundancy and application reachability first.
1. Define the retirement scope
Record hostname, manufacturer, model, serial number, asset tag, software release, rack position, management address, role and change reference. Identify whether the device is standalone or part of a stack, Virtual Chassis, chassis, MLAG pair or fabric.
2. Build physical and logical dependency maps
Capture connected devices, trunks, routed interfaces, port channels, fibre paths, WAN circuits, firewalls, servers, wireless systems and management networks. Compare live discovery with diagrams and the CMDB.
3. Why an apparently unused switch may still be critical
A switch with few access ports can still provide a transit trunk, spanning-tree root role, routing gateway, stack control function, peer link, fabric role or out-of-band path. Low interface utilisation is not proof of redundancy.
4. Securely preserve the configuration
Retain an approved configuration backup where policy requires it. Treat configuration as sensitive because it can reveal topology, addressing, routing, AAA, SNMP settings, certificates and security relationships.
5. VLANs and trunks
Inventory access and tagged VLANs, native VLAN behaviour, voice and management VLANs. Confirm a VLAN's remaining path to its gateway and services before removing it from a trunk.
6. LACP and port-channels
Removing one member may not cause an immediate outage because traffic moves to surviving links, but capacity and resilience can fall. Check LACP state, members, peer configuration and utilisation before change.
7. Spanning Tree Protocol
Identify root and secondary-root roles, forwarding and blocked ports, and the expected topology after removal. A blocked port may be the planned recovery path after another failure.
8. HSRP and VRRP
Identify active/standby state, priorities, tracked objects, virtual addresses and pre-emption behaviour. Prove the surviving gateway carries production traffic before retiring its peer.
9. Static routing
Review routes on the retiring device and routes on adjacent routers, firewalls and load balancers that may still point towards it. Dependencies often exist outside the device being removed.
10. OSPF and IGP relationships
Document neighbours, areas, metrics and redistribution. Predict the post-change topology and observe adjacency and route changes during implementation.
11. BGP considerations
Inventory peers, address families, policies, prefix filters, communities, route reflectors and redistribution. Validate critical prefixes after withdrawal and coordinate external peer changes where required.
12. Never remove both sides of redundancy together
Change one redundancy member at a time where practical and validate service before proceeding. Hardware described as redundant is not necessarily operating redundantly.
13. Cisco stacks
Identify active/control roles, member numbering, stack links, provisioning and interfaces physically hosted by each member. Follow the supported workflow for the exact Cisco platform and release.
14. Juniper Virtual Chassis
Identify primary/backup Routing Engine roles, member IDs, VCP topology and member-specific interfaces. Juniper documents that on applicable EX/QFX Virtual Chassis and VCF systems, request system zeroize operates only on the member where it is run; members intended for sanitisation may need to be isolated and processed individually.
15. MLAG and MC-LAG
Document peer links, keepalives, dual-attached downstream devices and orphan ports. Understand platform split-brain and failure behaviour before retiring either peer.
16. EVPN/VXLAN fabrics
A spine or leaf can participate in underlay routing, BGP EVPN, VTEP services, anycast gateways or route reflection. Check EVPN routes, VNIs, VTEPs, BGP sessions and endpoint reachability before and after withdrawal.
17. Fibre and optics
Trace both ends before removal. Record patch-panel/cross-connect references and protect unused interfaces. Keep reusable transceivers under asset control.
18. WAN and carrier circuits
Physical router removal and commercial circuit cessation are separate. Confirm carrier ownership, contractual termination and cross-connect actions.
19. Management and out-of-band services
Identify management ports, console servers, management VRFs and loopbacks. Remove the retired device from configuration management, monitoring, IPAM, DNS, AAA, backup and automation systems after final validation.
20. TACACS+, RADIUS and credentials
NCSC recommends controlling administrative credentials and changing or revoking credentials associated with retiring devices as appropriate. Review local accounts, SSH keys, SNMP communities and automation secrets.
21. Certificates
NCSC recommends revoking certificates associated with network devices before disposal, including operational, management and maintenance certificates. Removing a certificate from hardware is not equivalent to revoking its trust relationship.
22. Logging and telemetry
Preserve logs required by policy. Confirm replacement devices are sending required syslog, SNMP or streaming telemetry before removing obsolete monitoring objects.
23. Prove the device is safe to remove
Use several evidence sources: interface counters, neighbour tables, MAC/ARP state, routing adjacencies and tables, spanning-tree state, LACP state, fabric control-plane data, monitoring history and application tests. Administratively withdraw services first and observe the network while rollback remains possible.
24. Controlled shutdown
Once the network is stable without the device, follow the supported shutdown/power-down process, then label and disconnect network, console, management and power cabling in a controlled sequence. See Data Centre Rack Decommissioning.
25. Cisco configuration erasure is platform-specific
Cisco IOS XE documentation describes clearing startup configuration with erase nvram, while also documenting filesystem-specific deletion/recovery behaviour. A generic configuration-delete command should therefore not be assumed to equal complete sanitisation on every platform.
26. Juniper zeroisation is platform-specific
Juniper documents request system zeroize as removing configuration information, user-created files and various secrets/private keys before rebooting to factory defaults. Behaviour differs across dual Routing Engines, Virtual Chassis/VCF and platforms that use request vmhost zeroize.
27. Factory reset versus sanitisation
NCSC recommends factory reset or device wiping as a general precaution and points organisations to secure media sanitisation guidance where relevant. Match the process to the exact hardware, data, storage technology and intended disposition.
28. Asset reconciliation
Capture serial, asset tag, model and disposition before equipment leaves controlled custody. Include removable media, modules and high-value optics where component-level tracking is required.
29. Recommended decommissioning sequence
- Approve scope and ownership.
- Capture physical/logical inventory.
- Secure configuration backup.
- Map VLAN, LACP, STP and gateway dependencies.
- Map static, OSPF/BGP and WAN dependencies.
- Identify stack/VC/MLAG/fabric roles.
- Validate replacement capacity.
- Define rollback.
- Withdraw traffic.
- Validate applications and network state.
- Observe before irreversible action.
- Revoke certificates/credentials as appropriate.
- Perform supported sanitisation.
- Verify sanitisation.
- Reconcile and remove assets.
- Update CMDB, diagrams and IPAM.
30. Key risk controls
| Risk | Example | Control |
|---|---|---|
| Layer 2 outage | Removing STP root/only trunk | Validate topology and forwarding state |
| Reduced resilience | Removing LACP/redundant peer | Validate surviving capacity |
| Routing black hole | Peer still points to old router | Review adjacent configurations/routes |
| Fabric impact | Retiring EVPN role incorrectly | Migrate role and validate control plane |
| Credential exposure | Old keys remain valid | Revoke/rotate and sanitise |
31. Common mistakes
- Trusting diagrams without checking live state.
- Calling a blocked STP link unused.
- Removing both redundancy members together.
- Ignoring static routes on adjacent systems.
- Using interface utilisation as the only dependency test.
- Ignoring stack/Virtual Chassis member roles.
- Ignoring EVPN/VXLAN functions.
- Assuming startup-config deletion equals full sanitisation.
- Forgetting certificates, AAA, SNMP and automation credentials.
32. How Compritech approaches network-device retirement
Compritech combines network engineering with IT asset disposition. Infrastructure is removed only after dependencies have been understood and safely withdrawn, followed by configuration/credential protection, sanitisation, asset reconciliation and final disposition.
Related guides: Cisco & Juniper Decommissioning, Firewall Decommissioning and Network Decommissioning Checklist.
33. Final takeaway
The safest decommission is one where physically unplugging the device is almost uneventful because engineering work has already proved production no longer depends on it. Discovery, controlled withdrawal, validation, credential revocation, sanitisation and reconciliation should precede final disposition.
Authoritative guidance
- UK NCSC — Network device lifecycle guidance
- UK NCSC — Decommissioning assets
- Juniper — request system zeroize
- Cisco — IOS XE configuration-file management
Planning a network infrastructure decommission?
Compritech provides engineer-led Cisco and Juniper commissioning and decommissioning, onsite support, secure asset removal, sanitisation, reconciliation and ITAD services across the UK.
Network engineeringDiscuss your project