Network Decommissioning Checklist UK

Retiring a network is not simply a matter of unplugging switches and arranging equipment collection. A router may still advertise a route used by a remote office. A firewall may terminate a third-party VPN that is absent from the current diagram. A switch can provide power to cameras, access points or telephones whose dependency was never recorded. A management appliance may contain credentials, configuration archives, certificates, logs and customer information long after production traffic has moved elsewhere.

For that reason, a controlled network decommission should be treated as an engineering change followed by a security, asset-management and disposal process. The objective is not merely to remove equipment. It is to prove that services were migrated safely, access was withdrawn, data was handled appropriately, assets were reconciled and the final outcome was recorded.

This checklist is intended for UK organisations planning an office closure, infrastructure refresh, cloud migration, data-centre exit, acquisition, consolidation or end-of-life network replacement.

Important: Every environment is different. This checklist supports planning but does not replace an organisation's change-management, cyber-security, data-protection, health-and-safety, contractual or regulatory obligations.

What is network decommissioning?

Network decommissioning is the controlled retirement of network infrastructure and its associated services, configurations, identities, data, licences, cabling and records.

The scope may include:

routers, switches and wireless controllers;
firewalls, VPN concentrators and security appliances;
load balancers, WAN optimisers and proxies;
access points, antennas and cellular gateways;
console servers, out-of-band management devices and KVM equipment;
network-management, monitoring and authentication platforms;
transceivers, line cards, power supplies and stacking components;
racks, patch panels, structured cabling and power distribution;
configuration backups, certificates, keys, logs and local storage media;
carrier circuits, DNS records, IP address allocations and support contracts.

A successful project retires both the physical device and the logical dependencies attached to it.

Why generic equipment removal is not enough

A logistics-only approach normally begins with a list of items to collect. An engineering-led approach begins with a service and dependency model.

Before removing a device, the project must establish what the device does, what depends on it, how administrators reach it, what sensitive information it contains, whether it is still forwarding traffic and what evidence is required after retirement.

The distinction matters because the highest-risk failures are often logical rather than physical:

a forgotten static route disrupts a business application;
an old VPN remains trusted after a supplier contract ends;
a firewall object continues to permit traffic to a retired network;
DNS, DHCP or RADIUS still references an appliance that has been removed;
a powered-down access switch also removes connectivity from CCTV or access control;
configuration backups retain passwords, pre-shared keys or private certificates;
a device sold for reuse still contains local accounts, logs or customer identifiers;
monitoring is removed before the migration has been proven stable.

The checklist below is structured around those risks.

Phase 1: Establish ownership, scope and authority

Do not begin with the rack. Begin with accountable ownership.

Confirm the business owner and technical authority

Record:

the executive or service owner accepting the change;
the technical lead responsible for the decommission plan;
the change, incident and security contacts;
the person authorised to approve destructive actions;
the asset owner and data owner;
the disposal provider and any subcontractors;
the person authorised to accept the final evidence pack.

Destructive actions should not depend on an informal verbal instruction. The project should have an approved scope, agreed success criteria and a named decision-maker for exceptions.

Define the boundary

Specify exactly what is in and out of scope:

sites, rooms, racks and cabinets;
production, test, development and disaster-recovery environments;
device hostnames, serial numbers and asset tags;
circuits, VLANs, VRFs, routing instances and security zones;
wireless networks and controllers;
management systems and configuration repositories;
associated servers, storage and removable media;
third-party or leased equipment;
cabling, optics, spares and accessories;
items that must remain operational.

Use a written exception list for anything physically present but excluded from the project.

Agree the required outcomes

Possible outcomes include:

redeployment within the organisation;
return to a lessor, carrier or manufacturer;
secure storage as a retained spare;
resale or remarketing;
component harvesting;
recycling;
physical destruction.

The outcome influences how the device should be handled, sanitised, packaged and evidenced.

Phase 2: Discover the real environment

Documentation is a starting point, not proof. Compare records against live technical evidence and a physical survey.

Build the asset inventory

Capture, where available:

manufacturer and model;
hostname and management address;
serial number, chassis ID and asset tag;
rack, unit position and site location;
software or firmware version;
module, line-card and transceiver inventory;
power-feed and PDU position;
support entitlement and ownership status;
local storage type;
intended disposition;
data-sanitisation requirement;
final reconciliation status.

Photograph rack elevations and device labels where permitted. Photographs should be controlled because labels, screens and cabling can expose sensitive information.

Correlate multiple sources

Compare the physical survey with:

the configuration management database;
monitoring and logging platforms;
network-management systems;
DHCP and DNS records;
IP address management;
authentication and privileged-access systems;
cloud and SD-WAN portals;
carrier inventories and invoices;
firewall-management platforms;
wireless-management systems;
vulnerability scanners;
support and licence portals.

If a device appears in only one source, investigate it. An unmonitored device can still carry production traffic, and a monitored device may already be disconnected.

Prove whether the device is active

Depending on the platform and approved access, examine:

interface status, descriptions and counters;
MAC address and ARP/ND tables;
routing neighbours and learned prefixes;
spanning-tree roles;
link aggregation and stacking state;
VPN sessions and tunnel counters;
NAT translations;
firewall session data;
PoE consumption;
wireless client and access-point state;
CPU, memory and environmental history;
recent logs and configuration changes;
monitoring data over a representative period.

A quiet interface is not automatically unused. Some disaster-recovery, management and batch-processing services remain idle for long periods.

Phase 3: Map dependencies before approving removal

The dependency map should explain what will fail if each component disappears.

Network dependencies

Check:

upstream and downstream links;
routed interfaces and default gateways;
static and dynamic routing;
VLAN trunks and native VLANs;
spanning-tree root and redundancy roles;
port channels, MLAG, virtual chassis or stacking;
first-hop redundancy protocols;
multicast, QoS and policy-based routing;
WAN, Internet and private circuits;
DNS, DHCP, NTP, AAA, PKI and logging dependencies;
out-of-band management paths.

Security dependencies

Review:

firewall policies and objects;
site-to-site and remote-access VPNs;
certificate and key usage;
RADIUS, TACACS+ and directory integrations;
access-control lists;
network access control;
IDS/IPS and security-monitoring feeds;
allowlists held by customers, suppliers or cloud services;
privileged accounts and emergency access;
API tokens, SNMP credentials and automation secrets.

Operational technology and facilities dependencies

Network ports can support systems outside the IT team's usual inventory, including:

CCTV;
door-access systems;
building-management systems;
alarm signalling;
telephony and emergency phones;
printers and specialist production devices;
environmental sensors;
meeting-room and audiovisual equipment.

Confirm ownership before disconnecting unidentified ports or PoE consumers.

Phase 4: Design the migration and rollback

A decommission without a rollback plan is an uncontrolled outage waiting to happen.

Define the migration sequence

The plan should state:

which replacement services must be ready;
how configuration will be migrated or rebuilt;
how traffic will be moved;
how success will be tested;
how long the observation period will last;
what triggers rollback;
who has authority to proceed to irreversible removal.

Preserve what may be required for recovery

Before change, capture approved copies of:

running and startup configurations;
software versions and boot variables;
licence information;
routing and neighbour state;
interface status and counters;
firewall and VPN state;
diagrams and rack elevations;
relevant logs;
configuration hashes;
photographs of critical connections.

Store backups in an access-controlled repository. A network configuration can contain credentials, community strings, pre-shared keys, internal addresses, certificate material and commercially sensitive topology information.

Define rollback precisely

“Reconnect the old switch” is not an adequate rollback plan.

Record:

the last reversible step;
configuration and cabling restoration instructions;
required engineers and access permissions;
expected rollback duration;
DNS, routing or carrier propagation considerations;
validation tests after restoration;
the maximum acceptable outage;
the point after which destruction or collection is prohibited until formal acceptance.

Phase 5: Control the change window

Before the window opens, confirm:

approved change record;
current diagrams and port maps;
verified console and out-of-band access;
replacement hardware and tested spares;
known-good configuration backups;
carrier and supplier escalation details;
engineer access to the site and racks;
correct cables, optics and console adapters;
monitoring dashboards and test accounts;
incident bridge and communication plan;
stop/go decision criteria.

Use a live activity log with timestamps, engineer names, actions, observations and approvals. This becomes part of the audit trail.

Phase 6: Remove logical trust before physical removal

Once migration is accepted, retire the device's identities and relationships deliberately.

Tasks may include:

removing routes, peers and obsolete network advertisements;
removing firewall rules, NAT entries and unused objects;
revoking certificates, VPN identities and pre-shared keys;
disabling local, service and automation accounts;
rotating shared credentials that may have existed on the device;
removing the device from RADIUS, TACACS+, monitoring and logging;
removing API tokens and orchestration integrations;
releasing or reserving IP addresses according to policy;
updating DNS and DHCP;
removing the asset from vendor cloud-management portals;
cancelling or transferring subscriptions and support contracts;
terminating circuits only after usage and contractual checks;
updating diagrams, inventories and the CMDB.

Removing physical equipment while leaving its identity trusted can create an avoidable security weakness.

Phase 7: Power down and remove safely

Use a controlled shutdown

Where supported:

save required evidence;
confirm that traffic has moved;
shut down services cleanly;
record the final state;
label every cable before removal;
isolate power feeds safely;
remove optics and modules according to the asset plan;
protect fibre connectors and sensitive interfaces;
use appropriate lifting and rack-removal methods.

Large chassis, UPS systems and densely cabled racks can create manual-handling and electrical risks. Use competent personnel and the organisation's health-and-safety procedures.

Maintain physical control

Record custody transitions from rack removal onwards:

date and time;
site and rack;
asset identifier and serial number;
engineer or custodian;
tamper-evident container or seal, where used;
vehicle or collection reference;
destination;
exceptions, damage or discrepancies;
signatures or digital acceptance.

Do not mix unidentified equipment into a bulk collection and attempt to reconstruct the inventory later.

Phase 8: Identify data-bearing components

Network equipment may store more than configuration files. Consider:

internal flash and SSDs;
removable compact flash or SD cards;
USB media;
hard drives in management appliances;
log partitions;
packet captures;
authentication databases;
configuration archives;
crash dumps;
certificates and private keys;
licensing and customer identifiers.

A device that does not boot must still be treated as potentially data-bearing. Failure to power on is not evidence that its storage is unreadable.

Phase 9: Select and verify sanitisation

The sanitisation decision should consider:

media type and technology;
information sensitivity;
whether the device will leave organisational control;
reuse, resale or destruction outcome;
manufacturer capabilities;
contractual requirements;
verification requirements;
whether failed or inaccessible media is present.

NIST SP 800-88 Rev. 2 describes a programme-based approach to media sanitisation based on information sensitivity, media and intended disposition. The NCSC also advises organisations to ensure data on electronic storage media cannot be read by unauthorised parties after it leaves organisational control.

Possible outcomes include an approved logical sanitisation process, cryptographic erasure where applicable and properly implemented, or physical destruction. A factory reset should not automatically be treated as sufficient evidence; its suitability depends on the device, storage implementation, sensitivity and assurance required.

Verification should answer:

Was the intended procedure completed?
Was the correct asset and media processed?
Did the procedure report success?
Were errors or inaccessible areas recorded?
Was the result independently reviewed where required?
Is there a certificate or record linking the outcome to the asset?

Phase 10: Decide reuse, resale, return or recycling

Do not classify every removed device as waste at the rack.

First determine whether it is:

owned and available for reuse;
leased or subject to return conditions;
held for forensic, legal or operational reasons;
suitable for redeployment;
suitable for tested resale after sanitisation;
suitable only for component recovery or recycling;
subject to a destruction requirement.

This decision affects asset value, environmental outcome, documentation and the point at which equipment legally becomes waste.

Where equipment is transported as waste, UK duty-of-care requirements may require the appropriate waste documentation. GOV.UK states that each load of non-hazardous business waste moved off premises needs a waste transfer note or another document containing the same information; hazardous waste may require different documentation. Organisations should also verify the status and authority of carriers and treatment partners relevant to the project.

Phase 11: Reconcile every asset and exception

Reconciliation should compare:

the approved scope;
the physical inventory;
collected assets;
serial numbers and asset tags;
discovered extras;
missing items;
data-bearing media;
sanitisation or destruction results;
reuse, resale and recycling outcomes;
waste documentation;
certificates and final reports.

Do not hide discrepancies inside a final total. Record and resolve them individually.

Examples include:

serial number unreadable;
asset found in a different rack;
module missing from chassis;
failed storage media;
device retained by the customer;
equipment owned by a carrier;
sanitisation unsuccessful;
asset quarantined for investigation.

Phase 12: Validate the environment after removal

Post-change testing should be service-based, not limited to device reachability.

Validate as applicable:

internal and external connectivity;
critical applications and user journeys;
routing convergence and path selection;
redundancy and failover;
firewall and VPN operation;
DNS, DHCP, NTP and authentication;
wireless coverage and access;
voice, video and collaboration services;
monitoring, logging and alerting;
backup, disaster recovery and management access;
facilities and operational-technology systems;
security scanning and exposure of retired addresses.

Monitor through an agreed observation period before authorising irreversible destruction or disposal.

Phase 13: Produce the final evidence pack

A professional network decommission should produce evidence that another person can audit without relying on the engineers' memory.

The pack may include:

approved scope and change reference;
final asset register;
before-and-after diagrams;
rack elevations;
activity and decision log;
migration and test results;
exception register;
chain-of-custody records;
sanitisation or destruction certificates;
configuration-retention or deletion record;
waste transfer or consignment documentation, where applicable;
reuse, resale and recycling report;
carrier and licence closure evidence;
customer acceptance;
lessons learned and residual risks.

Agree retention periods and access controls for the evidence. The pack itself may contain sensitive infrastructure information.

Network decommissioning go/no-go checklist

Before authorising physical removal, confirm:

[ ] Scope and exclusions are approved.
[ ] Business and technical owners are named.
[ ] Physical inventory is reconciled with live sources.
[ ] Active traffic and long-idle dependencies have been assessed.
[ ] Routing, switching, security and facilities dependencies are documented.
[ ] Replacement services have passed testing.
[ ] Configuration evidence is secured appropriately.
[ ] Rollback steps, duration and authority are defined.
[ ] Monitoring remains active during the observation period.
[ ] Circuits, licences and vendor portals are accounted for.
[ ] Credentials, keys, certificates and trusted relationships have a retirement plan.
[ ] Data-bearing components are identified.
[ ] Sanitisation or destruction requirements are approved.
[ ] Asset ownership and intended disposition are confirmed.
[ ] Collection, custody and transport arrangements are documented.
[ ] Health-and-safety and site-access controls are complete.
[ ] Final validation and acceptance criteria are agreed.
[ ] Evidence-pack ownership and retention are defined.

If any of these items is unknown, the appropriate response is normally to investigate, not to disconnect and hope.

Questions to ask a network decommissioning provider

Before appointing a supplier, ask:

Who performs the technical discovery and validates dependencies?
Can you interpret configurations and live network state, or do you only remove equipment?
How do you separate customer-owned, leased, retained and waste assets?
How are serial numbers captured and reconciled?
How do you control chain of custody?
How are storage media, configurations, logs, credentials and keys handled?
What sanitisation methods and verification records are available?
How are failed or inaccessible devices managed?
Which activities are subcontracted?
What waste documentation and downstream processing evidence is supplied?
How are changes, exceptions and rollback decisions recorded?
What does the final project evidence pack contain?

The engineering-led difference

The value of an engineering-led decommission is not that engineers can unplug equipment more carefully. It is that they can understand what the equipment is doing before it is unplugged.

That means tracing dependencies, interpreting routing and switching state, identifying security relationships, planning a reversible migration, recognising data-bearing components and producing records that connect technical shutdown to final asset disposition.

Compritech combines network and security engineering experience with IT asset disposition, secure data handling, asset-level reporting and responsible recovery. This allows organisations to plan infrastructure retirement as one controlled lifecycle—from discovery and migration through removal, sanitisation, reuse, recycling and final evidence.

Planning a network decommissioning project?

Prepare the following information before requesting an assessment:

site location and access restrictions;
approximate number of racks and devices;
known manufacturers and platforms;
reason for decommissioning;
target completion date and permitted change windows;
whether services are live;
availability of diagrams and configurations;
data-security requirements;
reporting and certificate requirements;
expected reuse, resale or recycling outcomes.

Compritech can review the technical and asset requirements and discuss an appropriate project approach.

Call: 020 8036 1152 Email: info@compritech.co.uk Website: https://compritech.co.uk/network-decommissioning/

Authoritative references

UK National Cyber Security Centre, *Decommissioning assets*: https://www.ncsc.gov.uk/guidance/decommissioning-assets
UK National Cyber Security Centre, *Acquiring, managing and disposing of network devices*: https://www.ncsc.gov.uk/guidance/acquiring-managing-and-disposing-network-devices
UK National Cyber Security Centre, *Secure sanitisation and disposal of storage media*: https://www.ncsc.gov.uk/guidance/secure-sanitisation-storage-media
NIST SP 800-88 Rev. 2, *Guidelines for Media Sanitization*: https://csrc.nist.gov/pubs/sp/800/88/r2/final
Information Commissioner's Office, *Disposal and deletion*: https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/records-management/disposal-and-deletion/
GOV.UK, *Waste transfer notes*: https://www.gov.uk/dispose-business-commercial-waste/waste-transfer-notes
GOV.UK, *When electrical and electronic equipment becomes waste*: https://www.gov.uk/guidance/when-electrical-and-electronic-equipment-eee-becomes-waste-weee

Planning a network decommission?

Compritech provides engineer-led network decommissioning, asset reconciliation, secure data handling and responsible disposition for UK organisations.

Explore network decommissioning Discuss your project

Network Decommissioning Checklist for UK Businesses