Data Centre Exit Checklist UK

A data centre exit is not complete when the final server leaves the rack. It is complete when services have been migrated and accepted, dependencies have been retired, data-bearing equipment has received an approved outcome, every asset and component has been reconciled, contractual obligations have been closed and the organisation can explain what happened from discovery through final disposition.

That distinction matters because data centre exits combine several risk domains at once. A programme may involve production applications, shared storage, network routes, firewalls, carrier circuits, remote access, licences, physical security, electrical isolation, lifting operations, customer data, leased equipment, valuable components, waste obligations and multiple third parties. If these workstreams are managed separately without a common control record, gaps appear between them.

This checklist gives UK organisations an engineer-led framework for office data rooms, colocation facilities, private data centres, hosting environments and consolidation projects. It is intended for infrastructure managers, programme leads, facilities teams, security and data-protection stakeholders, procurement teams, insolvency practitioners and organisations appointing a specialist decommissioning provider.

Important: Every facility and technology estate is different. The plan must reflect the organisation’s change-management, data-protection, cyber-security, health-and-safety, environmental, contractual and regulatory responsibilities. Destructive actions should be approved explicitly and performed only after rollback is no longer required.

What is a data centre exit?

A data centre exit is the controlled withdrawal of an organisation’s services, infrastructure, people, assets and contractual dependencies from a facility or defined technical environment.

The programme may include:

migrating applications and data to another data centre or cloud platform;
consolidating services into a smaller estate;
retiring systems that are no longer required;
terminating carrier circuits and cross-connects;
removing servers, storage, network and security equipment;
sanitising or destroying data-bearing media;
returning leased or vendor-owned equipment;
recovering value from reusable assets;
recycling equipment that has reached end of life;
removing racks, cabling and power infrastructure where required;
closing access lists, support contracts, licences and facility agreements;
producing evidence that assets and services have been reconciled.

A successful exit addresses the logical environment, the physical estate and the records connecting both.

Why data centre exits fail

Most failures are not caused by one dramatic mistake. They result from several small assumptions that were never validated.

Common examples include:

a server believed to be dormant still runs a scheduled process;
an old switch carries an unrecorded management or backup network;
a firewall terminates a third-party VPN missing from the current diagram;
storage cannot be removed because a replication dependency remains active;
an application has migrated but its DNS, certificate or monitoring dependency has not;
equipment in the rack belongs to a carrier, lessor or another customer;
chassis serial numbers are recorded but removable drives and high-value modules are not;
sanitisation evidence cannot be matched to the original collection inventory;
a facility deadline arrives before safe migration and removal can be completed;
power, lifting or access restrictions were discovered only on removal day;
certificates are issued for a batch but asset exceptions remain unresolved.

The solution is a single controlled plan that connects discovery, migration, decommissioning, logistics and reconciliation.

Phase 1: Establish governance and decision authority

Appoint accountable workstream owners

Define responsibility for:

programme sponsorship;
application and service ownership;
network and security engineering;
server, virtualisation and storage engineering;
cloud migration;
facilities and electrical safety;
cyber security;
data protection and records retention;
asset and financial ownership;
commercial and contractual closure;
logistics and site access;
data sanitisation and destruction;
environmental compliance;
final reconciliation and acceptance.

Create a clear escalation path. Engineers should know who can accept risk, approve an exception, extend an outage or authorise irreversible destruction.

Define completion criteria

Agree what “exit complete” means before work begins. Suitable criteria may include:

all in-scope services migrated, retired or formally excepted;
business and technical validation completed;
no production dependency remains on the old facility;
all circuits and cross-connects addressed;
every asset has a recorded outcome;
data-bearing media has an approved and evidenced treatment;
leased and third-party equipment has been returned correctly;
waste and recycling documentation has been received where applicable;
the facility has accepted the physical handback;
financial, licence and support obligations have been closed;
the final evidence pack has been approved.

Without agreed criteria, teams can declare success at different points and leave the programme with unowned residual risk.

Phase 2: Define the scope and exit deadline

Establish the physical boundary

Record:

facility, building, room, cage and suite;
rack and cabinet identifiers;
storage rooms, staging areas and loading bays;
power feeds, PDUs and remote power equipment;
meet-me-room connections and cross-connects;
structured cabling, patch panels and fibre trays;
crash carts, console servers and tooling;
spares, packaging and loose components;
equipment outside the primary white space;
items specifically excluded from removal.

Establish the logical boundary

Include:

business applications and databases;
physical and virtual servers;
hypervisors and management clusters;
storage arrays, SAN fabrics and backup platforms;
routers, switches, load balancers and firewalls;
VPNs, DNS, DHCP, NTP, AAA and PKI;
monitoring, logging and configuration backup;
cloud connections and private links;
WAN and Internet circuits;
disaster-recovery and replication relationships;
automation, orchestration and service accounts;
licences, subscriptions and support agreements.

Work backwards from immovable dates

Facility contract termination, lease expiry, power-down windows and carrier cessation dates can impose hard constraints. Build the schedule backwards to allow for:

discovery and data quality improvement;
procurement and lead times;
migration rehearsals;
carrier notice periods;
change freezes;
business testing;
stabilisation periods;
secure sanitisation;
specialist lifting and logistics;
exception resolution;
facility handback.

Do not plan physical removal for the final contractual day. Contingency is essential when assets, carriers or dependencies do not match the records.

Phase 3: Build the master inventory

Record rack-level information

For each rack, capture:

facility and room;
cage or suite;
rack identifier;
rack unit positions;
A and B power feeds;
PDU identity and outlet mapping;
patch-panel and cable routes;
weight or floor-loading considerations;
ownership and handback requirement;
authorised photographs and rack elevations.

Record each chassis and component

Capture, where available:

manufacturer and model;
serial number and asset tag;
hostname and management address;
rack and unit position;
owner and cost centre;
operating system or firmware;
support status;
service and application relationships;
chassis modules, supervisors and line cards;
processors, memory and accelerator cards;
network and storage adapters;
power supplies and fans;
transceivers and DACs;
disk, SSD, flash and removable media identifiers;
lease, rental or third-party status;
intended migration or disposition outcome;
reconciliation status.

A single line reading “one storage array” is not enough when the array contains controllers, shelves and hundreds of individually data-bearing drives.

Reconcile multiple data sources

Compare the physical survey against:

CMDB and fixed-asset registers;
virtualisation and cloud-management platforms;
server and storage management tools;
network-management systems;
monitoring, SIEM and vulnerability scanners;
configuration backup and privileged-access systems;
DNS, DHCP and IP address management;
backup catalogues and replication platforms;
procurement and finance records;
maintenance contracts and vendor portals;
facility access and rack schedules;
carrier invoices and cross-connect records.

Treat differences as managed exceptions. A device absent from the CMDB may still provide a critical service, and an item in the register may already have been removed without the record being updated.

Phase 4: Discover service and infrastructure dependencies

Start with business services

For each service, identify:

business owner;
technical owner;
service criticality;
users and locations;
availability and recovery requirements;
maintenance windows;
upstream and downstream applications;
databases and message queues;
identity and certificate dependencies;
monitoring and support arrangements;
migration or retirement decision.

The hardware inventory explains what exists. The service map explains why it matters.

Map compute and virtualisation dependencies

Review:

hypervisor clusters and management servers;
virtual machine placement and affinity rules;
shared datastores;
host profiles and distributed switching;
time, DNS and authentication dependencies;
backup proxies and repositories;
replication and disaster-recovery orchestration;
hardware pass-through and appliance dependencies;
licence servers;
dormant or powered-off virtual machines;
templates, snapshots and retained images.

A powered-off virtual machine may still be subject to retention, legal hold or recovery requirements. Do not delete it solely because it is inactive.

Map storage and backup dependencies

Document:

storage arrays and shelves;
SAN switches and fabrics;
zoning and host mappings;
volumes, LUNs and file services;
snapshots and replication;
backup jobs and retention;
tape libraries and removable media;
encryption and key-management systems;
management appliances;
support utilities and call-home services.

Confirm that required data has been migrated and validated before dismantling storage. An application test alone may not prove that historical, archived or backup data is available in the new environment.

Map network and security dependencies

Check:

routing adjacencies and static routes;
VLANs, VRFs and gateway redundancy;
spanning tree, port channels and multi-chassis links;
Internet, WAN and private circuits;
firewalls, policies and NAT;
site-to-site and remote-access VPNs;
load balancers, proxies and DNS services;
out-of-band management;
AAA, PKI, NTP and logging;
cloud interconnects;
customer and supplier allowlists;
monitoring and telemetry.

Observe live state over a representative period. Backup, month-end, disaster-recovery and supplier services may remain quiet during a short survey.

Phase 5: Classify every workload and asset

Assign each service and asset one controlled outcome:

migrate as-is;
transform or rebuild;
consolidate;
archive;
retain temporarily;
retire;
return to owner or lessor;
redeploy internally;
remarket after sanitisation;
recover for parts;
recycle;
physically destroy.

Record the decision owner, target date, prerequisites and evidence required. Items without an owner should not drift into an undefined “remove later” category.

Phase 6: Design migration waves

Group by dependency, not convenience

Migration waves should keep tightly connected services together or define a controlled transition between them. Consider:

shared databases;
network latency;
authentication;
storage replication;
application release dependencies;
firewall and DNS changes;
business calendars;
support-team availability;
rollback complexity.

Moving the easiest servers first can leave the most interconnected estate compressed into the final weeks.

Define entry and exit criteria for each wave

Entry criteria may include:

target capacity available;
backups verified;
replication healthy;
firewall and routing changes approved;
rollback resources ready;
service owners available;
monitoring prepared.

Exit criteria may include:

functional testing passed;
performance accepted;
security controls verified;
backups operating in the target environment;
monitoring and alerting confirmed;
business owner sign-off;
stabilisation period completed;
old service approved for retirement.

Preserve a credible rollback point

Document:

the last reversible step;
data divergence implications;
restoration and traffic-return procedure;
decision authority;
maximum rollback time;
required people and access;
post-rollback validation.

Do not erase, dismantle or remove the old platform while it remains part of the approved rollback plan.

Phase 7: Manage carriers, cross-connects and external parties

Build a circuit register containing:

provider;
service identifier;
demarcation point;
local and remote endpoints;
bandwidth and service type;
technical and commercial owners;
dependent services;
contract and notice period;
migration date;
cessation date;
equipment-return requirements;
final billing confirmation.

Coordinate cross-connect removal with the data-centre operator. Confirm which cabling and termination equipment belongs to the organisation and which belongs to the facility or carrier.

Delay cancellation until migration and rollback requirements have been satisfied, but avoid paying indefinitely for circuits that no longer support a service.

Phase 8: Control security throughout the exit

Protect the old and new environments simultaneously

During transition, the attack surface can temporarily increase. Maintain:

patching and vulnerability management;
privileged-access controls;
logging and monitoring;
firewall governance;
physical access control;
secure remote support;
backup and recovery;
incident-response coverage.

Do not weaken controls merely because equipment is scheduled for retirement.

Remove residual trust

At the correct closure stage, withdraw:

local and central administrative accounts;
RADIUS and TACACS+ entries;
SSH keys and automation credentials;
API tokens and service accounts;
SNMP communities and credentials;
certificates and private keys;
VPN identities and pre-shared keys;
allowlist entries;
cloud-management assignments;
monitoring and configuration-backup jobs;
remote vendor access.

Where credentials may exist outside the retired device, revoke or rotate them rather than relying only on deletion from the hardware.

Phase 9: Plan safe power-down and physical work

Produce an authorised shutdown sequence

The sequence should account for:

applications and databases;
backup and replication;
virtual machines and hypervisors;
storage hosts and fabrics;
storage arrays and shelves;
network and security devices;
management platforms;
out-of-band systems;
facility monitoring where in scope.

Record who confirms each stage and how unexpected activity is handled.

Control electrical risk

Identify:

A and B feeds;
shared PDUs;
hard-wired equipment;
UPS and battery systems;
stored energy;
facility isolation rules;
authorised electrical personnel;
lockout or permit requirements;
proof-of-isolation method.

Follow the facility’s procedures and applicable electrical-safety arrangements. A powered-down operating system does not itself prove electrical isolation.

Control manual handling and lifting

Assess:

chassis and rack weights;
high or awkward rack positions;
rails and fixing methods;
centre of gravity;
sharp edges and damaged equipment;
lifting aids and rated equipment;
route to the loading area;
floor, lift and ramp capacity;
team size and competence;
packaging and palletisation.

Heavy servers, storage shelves and populated chassis should not be removed through improvised manual lifting. HSE guidance emphasises avoiding hazardous manual handling where reasonably practicable and assessing and reducing the risk where it cannot be avoided.

Phase 10: Create the de-racking method

For each rack or controlled group of racks:

confirm migration and retirement approval;
verify device identity against the work pack;
capture authorised final evidence;
isolate and label power and data connections;
remove or secure data-bearing media according to the plan;
remove cables without disturbing retained services;
de-rack equipment using the approved handling method;
record chassis and component identifiers;
assign the correct custody container or pallet;
update the live reconciliation record;
inspect the rack for missed equipment or media;
obtain rack or area completion sign-off.

Use a controlled deviation process when the physical estate differs from the work pack. Never place an unidentified device into a general recycling load.

Phase 11: Handle data-bearing assets appropriately

Identify where data may exist

Data can reside in:

server hard disks and SSDs;
storage-array drives and cache modules;
backup appliances and tape media;
hyperconverged nodes;
network and security device flash or SSDs;
management appliances;
removable USB or SD media;
failed drives retained in trays;
encrypted devices whose keys are managed separately;
printers, consoles and peripheral appliances.

Do not assume failed or inaccessible equipment is data-free. The ICO notes that data may remain accessible even when a device does not power on normally.

Choose the treatment based on risk and destination

Possible outcomes include:

verified sanitisation for reuse;
cryptographic erasure where suitable and approved;
manufacturer-supported secure erase;
degaussing for compatible magnetic media;
physical destruction;
controlled quarantine pending a decision.

The method should reflect the media type, condition, sensitivity, destination and organisational policy. A factory reset or ordinary deletion should not be treated automatically as secure sanitisation.

Manage exceptions

For failed processing, record:

asset and media identifier;
attempted method;
failure or error;
custody location;
risk decision;
authorised alternative treatment;
final result and evidence.

Exceptions should remain visible until resolved rather than being absorbed into a batch certificate.

Phase 12: Maintain secure chain of custody

At every transfer, record:

date and time;
releasing and receiving parties;
facility and location;
item or container identifiers;
expected and actual quantities;
seals where used;
vehicle or transport reference where appropriate;
destination;
discrepancies and exceptions.

Use controlled staging areas with restricted access. Keep data-bearing assets separate from general cabling, packaging and non-sensitive equipment.

The custody record should allow the organisation to trace an asset from its rack position through collection, processing and final disposition.

Phase 13: Separate owned, leased and third-party equipment

Before removal, classify assets as:

customer-owned;
leased or financed;
carrier-owned;
vendor loan or demonstration equipment;
facility-owned;
third-party customer equipment;
ownership unresolved.

Confirm return conditions, packaging, configuration, data handling and serial numbers. Sanitising or disposing of equipment without authority can create contractual and operational problems; returning it without addressing customer information creates security risk.

Quarantine ownership disputes until documentary evidence and authorisation are available.

Phase 14: Recover residual value responsibly

After the approved data outcome, evaluate equipment for:

internal redeployment;
resale or remarketing;
tested parts recovery;
manufacturer take-back;
recycling.

Assessment should consider:

age and support status;
configuration and market demand;
cosmetic and functional condition;
complete component inventory;
licence transferability;
sanitisation result;
testing cost;
transport and processing cost;
security and reputational risk.

Value recovery should never take priority over verified data handling or ownership controls.

Phase 15: Manage equipment that becomes waste

Not every removed asset is automatically waste. The classification depends on its condition, intended reuse, testing and applicable legal requirements. When equipment becomes WEEE, use an appropriate route and maintain the documentation required by the organisation’s duty of care.

Controls may include:

checking the carrier and receiving facility;
describing the waste accurately;
using applicable waste transfer or consignment documentation;
separating equipment requiring special treatment;
recording quantities and destinations;
retaining evidence of treatment or recycling;
checking downstream subcontracting.

Do not describe untested or unusable equipment as reusable merely to avoid the controls associated with waste.

Phase 16: Reconcile assets at every stage

Reconciliation should not be postponed until the end. Perform it at defined gates.

Gate 1: Discovery reconciliation

Compare physical findings with the CMDB, asset register, rack schedule and financial records.

Gate 2: Migration reconciliation

Confirm every service and asset has a migration, retirement, retention or exception decision.

Gate 3: De-racking reconciliation

Compare what was physically removed with the approved rack work pack.

Gate 4: Processing reconciliation

Match received assets and media to sanitisation, testing, destruction and disposition results.

Gate 5: Final reconciliation

Account for every item as:

migrated and retained;
redeployed;
returned;
sold or remarketed;
sanitised and reused;
destroyed;
recycled;
quarantined exception;
missing or unresolved.

No project should close with unexplained quantity differences or serial-number gaps.

Phase 17: Control the exception register

Each exception should include:

unique reference;
date identified;
asset or service affected;
description;
risk and impact;
owner;
immediate containment;
required decision;
due date;
supporting evidence;
final resolution;
approver and closure date.

Typical exceptions include missing serial numbers, unexpected live services, failed drives, ownership disputes, damaged equipment, unavailable keys, incomplete backups, inaccessible racks and differences between collected and received quantities.

An exception is not a failure if it is identified, controlled and resolved. An undocumented discrepancy is the real risk.

Phase 18: Complete the facility handback

Agree the handback standard with the operator. It may require:

racks emptied or removed;
cabling and patching removed to an agreed boundary;
cross-connects ceased;
floor tiles and containment restored;
cages, storage and staging areas cleared;
access cards and keys returned;
damage recorded and repaired;
waste and packaging removed;
photographs and joint inspection completed;
power and capacity records updated;
formal acceptance received.

Avoid assumptions about “broom clean” or rack-removal obligations. Use the contract and written facility instructions.

Phase 19: Close logical, commercial and security records

Update or close:

CMDB and asset registers;
network and application diagrams;
DNS, DHCP and IPAM;
monitoring and backup systems;
firewall, VPN and routing objects;
privileged-access records;
certificates and secrets;
vulnerability-scanner targets;
support and maintenance contracts;
software licences and subscriptions;
carrier and facility billing;
insurance schedules;
disaster-recovery documentation;
supplier access;
rack, power and capacity data.

Keep sufficient evidence under the organisation’s retention policy, but do not retain sensitive configurations or personal information without a defined need.

Phase 20: Assemble the final evidence pack

A defensible completion pack may contain:

governance and responsibility matrix;
approved scope and exclusions;
discovery inventory;
rack elevations and authorised photographs;
service and dependency maps;
migration-wave records;
change approvals and validation results;
circuit and cross-connect closure evidence;
shutdown and de-racking work packs;
chain-of-custody records;
asset and media processing results;
sanitisation and destruction certificates;
return-to-lessor evidence;
remarketing and value-recovery statement;
waste documentation where applicable;
exception register and resolutions;
facility handback acceptance;
final asset reconciliation;
lessons learned and management sign-off.

The evidence should tell one coherent story from the original rack position to the final recorded outcome.

Data centre exit master checklist

Governance and commercial controls

Programme sponsor and workstream owners appointed.
Exit scope and completion criteria approved.
Facility contract and handback requirements reviewed.
Carrier, lease, support and licence notice periods recorded.
Destructive actions and risk acceptance authority defined.
Exit schedule contains contingency before the hard deadline.

Discovery and inventory

All rooms, cages, racks and storage areas surveyed.
Rack elevations and power feeds recorded.
Chassis, modules and data-bearing media identified.
Physical findings reconciled with CMDB and asset records.
Ownership and lease status confirmed.
Unknown and disputed assets entered in the exception register.

Dependencies and migration

Business-service owners confirmed.
Compute, storage, network and security dependencies mapped.
Backup, replication and archive requirements validated.
Carrier and cross-connect dependencies recorded.
Migration waves and success criteria approved.
Rollback procedures tested or reviewed.
Stabilisation and business acceptance completed.

Security and data handling

Security controls maintained during transition.
Required configurations and records preserved securely.
Administrative, automation and supplier access withdrawn.
Certificates, keys and secrets revoked or rotated where required.
Every data-bearing component assigned a treatment.
Sanitisation results verified.
Failed or inaccessible media controlled as exceptions.

Physical work and logistics

Shutdown sequence approved.
Electrical isolation arrangements confirmed.
Manual-handling and lifting risks assessed.
Data-centre access, escorts and loading arrangements booked.
Packaging, cages, pallets and transport capacity prepared.
Chain-of-custody documentation ready.
De-racking completed against controlled work packs.

Asset disposition

Customer, lessor, carrier and facility assets separated.
Reusable equipment tested after approved sanitisation.
Remarketing and value-recovery decisions documented.
WEEE classification and duty-of-care requirements addressed.
Downstream recycling or destruction evidence received.
Components and removable media reconciled separately where needed.

Closure and reconciliation

Racks and facility areas inspected jointly.
Cross-connects and circuits closed.
CMDB, DNS, monitoring and security records updated.
Contracts, licences and billing closed or transferred.
All asset and service exceptions resolved or formally accepted.
Final inventory balances collected, received and processed items.
Evidence pack accepted and project signed off.

Common data centre exit mistakes

Starting with removal instead of discovery

Physical removal is one of the last stages. Beginning there increases outage, security and reconciliation risk.

Treating the CMDB as proof

The CMDB is a valuable source, but it must be compared with physical and live technical evidence.

Migrating applications without infrastructure dependencies

DNS, certificates, identity, logging, backup, monitoring, routing and firewall rules can remain tied to the old site.

Cancelling circuits too early

Carrier services may still support migration, replication, management or rollback.

Cancelling circuits too late

Without a commercial closure plan, unused services can continue generating costs after the exit.

Erasing equipment before rollback expires

Once configuration or data is destroyed, the old environment may no longer support recovery.

Recording only chassis serial numbers

Storage drives, modules, optics and other components may move independently and require separate accountability.

Using a batch certificate without underlying reconciliation

A certificate is useful only when it can be connected to the original assets and exceptions.

Ignoring health and safety until removal day

Heavy equipment, live power, restricted aisles and facility rules require advance planning.

Closing with unresolved discrepancies

An unexplained missing drive or asset cannot be corrected by declaring the programme complete.

Questions to ask a data centre decommissioning provider

Who performs the technical discovery and dependency validation?
Can you work across servers, storage, virtualisation, networking and security?
How are rack, chassis, module and media identifiers captured?
How do you prevent removal before migration and rollback approval?
What electrical, lifting and site-safety controls do you use?
How are assets controlled between the rack and the processing location?
Can each sanitisation or destruction result be matched to an asset or drive?
What happens when equipment fails processing or ownership is unclear?
How do you separate reuse, resale, returns and recycling?
Which downstream organisations handle equipment and waste?
What reconciliation and evidence will be delivered at project closure?

Why an engineer-led exit produces better evidence

A generic removal team can count boxes. An engineering-led team can understand why the equipment is present, determine whether it remains operationally relevant, recognise hidden network and storage dependencies, preserve rollback, and connect the technical retirement decision to the physical asset outcome.

That technical understanding is particularly important in mixed estates. A low-traffic switch can still carry a management network. A powered-off server can still contain regulated data. An apparently empty storage shelf may hold failed drives. A carrier device can sit beside customer-owned equipment with no obvious visual distinction. These are not unusual exceptions; they are routine realities of long-lived data-centre environments.

Compritech combines infrastructure engineering, data-centre decommissioning, asset identification, secure data handling, chain of custody, value recovery and responsible recycling. The objective is not merely to clear the room. It is to leave the organisation with services protected, assets accounted for and evidence capable of supporting operational, security and audit review.

Further authoritative guidance

NCSC: Decommissioning assets — https://www.ncsc.gov.uk/guidance/decommissioning-assets
NCSC: Network security fundamentals — https://www.ncsc.gov.uk/guidance/network-security-fundamentals
NCSC: Acquiring, managing and disposing of network devices — https://www.ncsc.gov.uk/guidance/acquiring-managing-and-disposing-network-devices
ICO: Asset management and secure hardware disposal — https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/information-and-cyber-security/asset-management/
ICO: Disposal and deletion — https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/records-management/disposal-and-deletion/
HSE: Electricity at work—safe working practices — https://www.hse.gov.uk/pubns/books/hsg85.htm
HSE: Manual handling at work — https://www.hse.gov.uk/msd/manual-handling/index.htm
GOV.UK: When electrical and electronic equipment becomes waste — https://www.gov.uk/guidance/when-electrical-and-electronic-equipment-eee-becomes-waste-weee
GOV.UK: Waste duty of care code of practice — https://www.gov.uk/government/publications/waste-duty-of-care-code-of-practice

Planning a data centre exit?

Compritech combines infrastructure engineering, controlled decommissioning, asset reconciliation, secure data handling, value recovery and responsible recycling.

Explore data centre decommissioning Explore server decommissioning Discuss your project

Data Centre Exit Checklist: From Discovery to Asset Reconciliation