This free server decommissioning checklist retires a server or the service on it without surprising anyone who still relies on it. It is written for infrastructure and operations teams, MSPs retiring servers for clients and anyone running a data centre exit or cloud migration. It walks through dependency discovery, change approval and notice, the final backup, a staged shutdown with a scream test, removal from every system that references the server and a platform-specific teardown for physical, virtual or cloud. It ends with a retired record in the CMDB, costs that have actually stopped and, for physical hardware, a documented hand-off to your IT asset disposal process.
A half-finished decommission is worse than none, because it looks finished. The server is gone, so nobody checks the things that pointed at it. A DNS name left pointing at a deleted cloud resource can be claimed by someone else: Microsoft calls these dangling DNS records, warns that they enable subdomain takeover, and recommends making DNS removal a required check when a service is decommissioned. A firewall rule left open for the old IP address applies to whatever is given that address next. A service account nobody uses is a credential nobody rotates.
The other failure is going too early. The CMDB rarely lists every consumer. The month-end report, the partner’s file transfer and the script with a hard-coded IP address show up only when they break. That is why the checklist finds dependencies from traffic, not just from records, and stages the shutdown so it can be reversed.
Covers: dependencies, approval, data retention, shutdown, cleanup across every connected system.
Owned by: the infrastructure team, under a change record.
Ends: with a retired CI and, for physical kit, hardware handed to ITAD.
Covers: chain of custody, media sanitisation, certificates, vendor checks, resale or recycling.
Owned by: IT asset management, often with an ITAD vendor.
Runs in: the IT Asset Disposal Checklist, which picks up where this one stops.
Seven phases, from finding out who still depends on the server to closing the record. The teardown tasks change with the platform you select, and a failed scream test sends the checklist back to discovery.
Treat the CMDB as the starting point, not the answer. Most surprises in a decommission come from consumers nobody recorded.
Nothing is deleted in this phase. Every step is reversible within minutes.
Tasks are shown for the platform chosen in Phase 1. Physical servers end with a hand-off to ITAD; sanitisation happens there, not here.
Every item in Phase 5 and Phase 6 is there because it outlives the server when nobody removes it. The table is a useful prompt when you adapt the template: if your environment has another system that references servers, add it.
| Left behind | What happens | Removed in |
|---|---|---|
| DNS records, especially CNAMEs to cloud resources | Dangling records can be taken over and used to serve content under your domain | Phase 5 |
| Firewall and NAT rules | Access intended for the old server is granted to the next device given its address | Phase 5 |
| Service accounts, certificates and secrets | Valid credentials with no owner and no rotation | Phase 5 |
| Monitoring checks and backup jobs | Daily failures that train the team to ignore real ones | Phase 5 |
| Cloud volumes, snapshots and static IPs | Charges continue after the instance is terminated | Phase 6 |
| Licences and support contracts | Renewals paid for a server that no longer exists | Phases 2 and 7 |
| An active CI in the CMDB | Incident responders and auditors chasing a server that is gone | Phase 7 |
In ITIL 4 terms, the decommission is authorised through the change enablement practice, and the CI’s status change is part of service configuration management. Teams working to ISO/IEC 27001:2022 will find the completed checklist supports Annex A 5.9 (inventory of information and other associated assets) and 8.10 (information deletion). Control 7.14, secure disposal or re-use of equipment, applies to the hardware after the hand-off, which is why that work sits in the disposal process rather than here.
The cleanest decommissions start at build time. A server built with an owner, a CMDB record and deliberate cloud volume settings is far easier to retire, which is why the server setup checklist captures all three on day one.
Dynamic due dates set the end of the scream test from the day the server was powered off, so the go decision lands on the right day without anyone counting. If a dependency surfaces, one answer shows the restore task and sends the work back to discovery instead of on to deletion.
DNS, firewall, identity, backup and monitoring usually belong to different people. Assign each cleanup task to the group that owns the system, and record each deleted DNS record or firewall rule in a table inside the task, so nobody has to ask whether it was done.
The owner’s agreement, the restore test, the ITAD hand-off and the final bill check are attached to the tasks they prove, with who completed each and when. When an auditor asks what happened to a server, you open one checklist instead of searching three ticket systems.
A decommission is a change like any other, and often a riskier one because its dependencies are the least documented. CheckFlow’s change management checklist software shows how approvals, rollback plans and post-implementation reviews run across every change, and the IT Change Management Checklist gives you the RFC-to-review process this template runs under.
Physical hardware leaves this checklist at the hand-off. The IT Asset Disposal Checklist covers sanitisation, certificates and the ITAD vendor, and the Backup Verification & Restore Test Checklist is the routine that keeps restore tests, like the one in Phase 3, from being the first in a year.
Server decommissioning is the controlled retirement of a server and the services it runs. It covers finding what depends on the server, getting approval, preserving the data that must be kept, shutting down in stages, removing the server from every system that references it and updating the CMDB. For physical servers it ends by handing the hardware to the IT asset disposal process, which handles data sanitisation and recycling or resale.
A scream test is a deliberate, reversible shutdown to find out whether anyone still depends on a server: you turn it off and wait to see who complains. It catches consumers that dependency discovery missed. There is no standard length. Set it from what the server does: long enough for every scheduled job it runs to have run at least once, including a month-end if it touches finance, payroll or reporting, and a quarter-end for anything used in quarterly processes. Never delete data during the test.
As long as the longest retention requirement on the data it held, which comes from your records retention schedule, contracts and any legal hold, not from the backup system’s default rotation. Keep the final backup outside normal rotation, labelled with the change reference, and test a restore before the server goes. When the retention period ends, delete it deliberately and record that you did.
No. Change its status to retired or decommissioned and keep the record. Past incidents, changes and audit evidence refer to that configuration item, and deleting it breaks those links. A retired status also stops the server appearing in active service maps and reports, which is what most people want when they ask to delete it.
Decommissioning retires the service: it removes the server from use and from every system that references it. IT asset disposal deals with the physical equipment afterwards: chain of custody, sanitising or destroying the storage media, certificates of destruction and choosing a reputable ITAD vendor. Virtual and cloud servers need only decommissioning. Physical servers need both, with a signed hand-off between the two.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
