Decommission Server Checklist: 30 Steps Across 3 Phases

What server decommissioning actually covers

Server decommissioning is the planned retirement of a physical or virtual server from production. The server decommissioning process covers four kinds of work. Logical removal: workloads, DNS, directory services, monitoring. Data sanitization: wipe the drive or destroy it. Physical handling: rack removal, transport, chain of custody. And recordkeeping: certificate of destruction, asset disposition manifest.

Done well, it yields the backup, custody, sanitization, and disposition records a HIPAA reviewer will ask for. Done poorly, it leaves stray credentials on the network and unchecked drives in a closet.

This checklist is scoped to one server at a time, physical or virtual. Shutting down a whole facility is a different job with a different plan, covered in security checklist for data center decommissioning.

ITAMG has retired enterprise servers since the 1990s. First came tower units and CRT terminals. Then 1U and 2U rack servers. Then blade chassis. Today it is a mix of dense compute and virtual instances on hyperconverged stacks. The work has changed. The controls that prevent breaches have not. The checklist below sets out those controls.

Why a 30-step checklist beats a 10-step one

Short checklists work fine for one low-risk server. Decommissioning a server under audit duties needs more. It needs dependency mapping, sanitization controls, custody records, and closeout proof.

Short checklists hide three risks. Dependencies nobody wrote down surface only after power-down. Drive sanitization gets applied to the wrong media class. And the asset disposition manifest goes missing on the day an auditor asks for it.

The 30-step decommission server checklist below covers the controls these projects tend to need: dependency mapping, media sanitization, chain of custody, and closeout proof. Each step targets a failure mode IT teams hit often. Missed dependencies. Thin records. Wrong media handling. Late evidence. The recordkeeping lines map to what HIPAA, R2v3, and SOX-style reviews tend to ask for.

For broader project context beyond a single server, see the data center decommissioning security checklist and ITAMG's data center decommissioning services. For background on the broader IT asset lifecycle, see what is the IT asset decommissioning process.

Phase 1: Pre-decommission (12 steps)

The pre-decom phase locks scope, permissions, and dependencies before anyone touches a service. Avoidable problems often start here. On a regulated server, allow enough time for dependency review, approvals, and rollback planning.

Step 1: Confirm executive sponsor and change ticket

Open a change ticket in your ITSM tool. Name an executive sponsor. Add scope, timeline, risk, and a rollback plan. With no ticket, there is no audit trail. Recorded: Change ticket number, sponsor name, approval date.

Step 2: Inventory the server and assign an asset ID

Capture make, model, serial number, asset tag, rack slot, MAC addresses, and the asset ID in your CMDB. The serial number ties every later step to this one box. Recorded: Hardware identifiers, location, CMDB asset ID.

Step 3: Classify the data on the server

Work out which data classes live on the server: PHI, PCI cardholder data, financial records, trade secrets, public. What you find here drives the sanitization method you pick in Step 19. Recorded: Data classification levels, regulatory framework applicability.

Step 4: Verify and test backups

Check that current backups exist for any data or config that has to survive. Then run a test restore on at least one key file or volume. NIST SP 800-34 Rev. 1 calls for testing contingency and recovery capabilities; record a successful restore test before decommissioning. Recorded: Backup job name, last successful run, restore test result.

Step 5: Audit services, applications, and dependencies

Pull every running service, scheduled task, and open port. Check the CMDB for the dependencies someone wrote down. Then check the server itself for the ones nobody did. Map what calls in and what it calls out to. Recorded: Services list, dependency map, undocumented findings.

Step 6: Identify license and software entitlements

List every paid license tied to the server: OS, hypervisor, database, monitoring agent, security tools. Some licenses move. Some have to be released. Some are locked to the hardware serial. Recorded: License keys, transfer or release plan per license.

Step 7: Notify all stakeholders with a published timeline

Email security, networking, database admins, app owners, infrastructure, compliance, and the help desk. Give them the start date, the power-down date, how long the wait runs, and the final disposition date. Name one point of contact. Recorded: Distribution list, notification dates, point of contact.

Step 8: Capture configuration and a final system image

Take a full disk image and a config snapshot before you change anything. Put the image in cold storage. Keep it as long as your records policy says. This is the last-resort rollback. Recorded: Image file path, hash, retention end date.

Step 9: Schedule the maintenance window

Pick a quiet window with a firm start and end time. Confirm it with downstream service owners and with anyone whose SLA depends on the server. Recorded: Window start, window end, SLA confirmations.

Step 10: Pre-stage rollback procedures

Write down the exact steps to bring the server back if the decom has to reverse. Cover power-on order, network rejoin, directory rejoin, and the order dependencies restart in. Recorded: Rollback runbook ID, last review date.

Step 11: Confirm chain of custody for hardware

Name who owns the hardware at every step, from the rack to final disposition. If a vendor is involved, confirm the pickup contact, the carrier, the destination site, and how fast the certificate of destruction comes back. ITAMG runs chain of custody under NAID AAA auditing rules. Recorded: Custodian names, transit plan, NAID AAA aligned signoff fields.

Step 12: Pre-issue the asset disposition manifest

Open the asset disposition manifest now, not at pickup. Fill in make, model, serial, asset tag, and data class. Leave blanks for sanitization method, tool, technician, and certificate ID. Recorded: Manifest ID, pre-filled rows.

When evaluating the partner who will handle Steps 11 through 30, see how to select an IT asset disposition vendor.

Phase 2: Decom day (10 steps)

Decom day is the day the server goes from live to powered down. Doing it fully matters more than doing it fast.

Step 13: Place the server in maintenance mode

Pause automated workflows, mute monitoring alerts, and set the load balancer to drain. Maintenance mode tells the rest of the estate that this server is going offline on purpose. Recorded: Maintenance mode start time, monitoring system acknowledgment.

Step 14: Migrate active workloads

Move services, apps, and data to their new homes, whether that is another physical server, a VM, or a cloud instance. Get the app owner to confirm each move before you go on. Recorded: Migration target per workload, owner signoff.

Step 15: Update DNS, load balancers, and service discovery

Take the server out of forward and reverse DNS. Drop it from load balancer pools. Remove it from service discovery: Consul, etcd, Kubernetes endpoints. Cut traffic at the edge before you touch the host. Recorded: DNS records changed, load balancer config diff.

Step 16: Disable the network interface

Once traffic has drained, shut the NIC down at the host and release the IP at the IPAM. The server is now unreachable but still powered. Recorded: NIC shutdown timestamp, IPAM release timestamp.

Step 17: Power down the server

Use a clean OS shutdown, not a hard power cut. A clean shutdown closes file handles and flushes write caches. That protects any data still on the drives. Recorded: Shutdown command, exit code, timestamp.

Step 18: Begin the waiting period

Leave the hardware in the rack, intact. If Step 5 missed a service, this is when someone notices. Set the hold long enough to cover your own dependency risk; on regulated or dependency-heavy servers many teams use two to four weeks. Send check-in emails while the hold runs. Recorded: Waiting period start, check-in dates, any incidents reported.

Step 19: Pick the sanitization method per drive

NIST 800-88 Rev. 2 sorts media sanitization into three categories: Clear, Purge, and Destroy. Pick the method for each drive from the NIST guidance for that media type, then verify it.

For HDDs, both Clear and Purge have options that depend on the media. NIST 800-88 Rev. 2 lists them. Pick the one that matches the drive type and interface, then verify it.

For SSDs and NVMe drives, the Purge options also depend on the media. They may include cryptographic erase, or sanitize and format commands the interface supports, where the drive supports them and you can verify the result. Software built to overwrite an HDD does not reach wear-leveled or over-provisioned cells on flash.

Destroy means shred, break up, or pulverize. Cryptographic erase relies on the firmware doing what the spec says, which is why Step 21 verification has to record the result. For very sensitive data, or when you do not need resale value, physical destruction is the safe call. Validated NIST 800-88 sanitization can also meet policy when you document it. Recorded: Drive serial, sanitization category (Clear, Purge, or Destroy), method used, decision rationale.

Step 20: Execute sanitization with a verified tool

Run the sanitization with a NIST 800-88-aligned tool that issues a certificate per drive. ITAMG can align sanitization evidence with NAID AAA chain-of-custody requirements for regulated projects. Recorded: Tool name, tool version, per-drive log file, technician ID.

Step 21: Verify the sanitization

For drives erased in software, run a check pass that samples the drive for leftover data. For destroyed drives, photograph the shredded state and tie the photo to the drive serial. NIST SP 800-88 Rev. 2 calls for verification as part of a documented sanitization program. Recorded: Verification log, photo file path, verifier name.

Step 22: Issue the certificate of destruction

Issue one certificate per drive. Or issue one per chassis with an appendix listing each serial. Every certificate names the drive serial, the sanitization method, the NIST 800-88 alignment, the technician, and the date. Recorded: Certificate ID, issuance date, recipient.

For ITAMG's broader approach to the data side of decommissions, see ensuring data integrity access during data center decommissioning and data privacy safeguards and process evaluation.

Phase 3: Post-decommission (8 steps)

Post-decom closes the paperwork, clears the server out of every system that still points at it, and sends the hardware to its final home.

Step 23: Remove from directory services

Delete the computer object from Active Directory, Entra ID, or whatever directory you run. Revoke any service accounts and Kerberos delegations tied to it. Recorded: Directory service, object DN, revocation timestamps.

Step 24: Remove from monitoring and configuration management

Pull the server out of monitoring: Datadog, Nagios, Zabbix, Prometheus. Then out of config management: Ansible, Puppet, Chef, SaltStack. Then out of orchestration: Kubernetes and Terraform state. Stale CMDB rows cause false alerts and bad capacity plans. Recorded: Tools touched, removal timestamps.

Step 25: Release software licenses

Release or move every license you listed in Step 6. Tell the vendor where a license is tied to a seat or to the hardware. Update your software asset ledger. Recorded: License IDs released or transferred, SAM ledger update.

Step 26: Decide disposition path

Newer enterprise hardware may still have resale value through an ITAD partner. Older or damaged hardware should go to recycling through an R2v3-certified processor. For leased equipment, route per the lease return terms after sanitization is complete. ITAMG can also help maximize asset recovery value in data center decommissioning. Recorded: Disposition path per asset, partner name.

Step 27: Complete the asset disposition manifest

Fill in every blank left on the Step 12 manifest: sanitization method, tool, technician, certificate ID, carrier, destination site, recipient signature. Lock it read-only once it is full. Recorded: Final manifest, lock timestamp.

Step 28: Close out the ITSM ticket

Attach the manifest, the certificates of destruction, the sanitization logs, and any photos to the Step 1 change ticket. Then move the ticket to closed-verified. Recorded: Ticket closure date, attached artifact list.

Step 29: Update CMDB, runbooks, and network diagrams

Mark the asset retired in the CMDB. Update any runbook that named the server IP or hostname. Refresh the network diagrams. Drop the host from monitoring dashboards. Recorded: Documents updated, version numbers.

Step 30: Run a post-mortem and update the checklist

Within thirty days, get the team together and ask three questions. What did Phase 1 miss? What went wrong on decom day? What turned up in Phase 3? Feed the answers into the next version of this decommission server checklist. Recorded: Post-mortem notes, checklist version increment.

For more on patterns ITAMG sees across decommission projects, see lessons learned from data center decommissioning projects.

Sample server decommissioning report

A solid server decommissioning report gives one row per asset. The columns are below. Adapt the decommission server template to fit the way your own ITSM and records work.

Vendor handoff template

When ITAD work moves to a vendor at Step 26, the packet that travels with the asset needs at least these seven items:

1. Asset disposition manifest from Step 12 / Step 27
2. Data classification record from Step 3
3. Required sanitization method per drive (or "physical destruction required")
4. Certificate-of-destruction template the vendor must use
5. Chain-of-custody form aligned to NAID AAA fields (Step 11)
6. Customer compliance contact for breach notification escalation
7. Authorized recipient list at the destination facility

Send a packet with every pickup, and get it signed on receipt. That first signature at the other end is the anchor for the customer chain of custody. For more on partner selection, see IT spring cleaning: 5 steps to creating an effective ITAD plan and ITAD sustainability.

Compliance cross-walk: which framework requires what

Most "server decommissioning" articles list HIPAA, PCI, and SOX as if they impose the same controls. They do not. Use the cross-walk below to match each framework to the checklist steps that support the right evidence.

The cross-walk above maps each framework's general disposal expectations to the decommission server checklist steps that produce supporting evidence. It is a planning aid, not legal advice, and it does not replace a compliance review.

Virtual servers: what changes

For a virtual server, Phase 1 is the same. Phase 2 shrinks, because there is no NIC to pull and no power button. Phase 3 changes at the disposition step.

Delete the VM and its virtual disks. Then confirm the disk files are gone from the datastore, not just orphaned. On shared or thin-provisioned storage, check how the platform handles deleted blocks, snapshots, replicas, and backups. Reclaiming blocks is not the same as sanitizing media. Treat physical-media sanitization as a separate control, applied when the host or the storage array itself is retired.

When a fleet of VMs retires along with the hardware under it, those physical hosts join the 30-step checklist at Step 13. For multi-server retirements that span racks or rooms, the same controls extend into the data center decommissioning process.

Common mistakes to avoid

Three failure patterns are worth calling out.

The first is skipping the waiting period (Step 18). Compressed timelines push teams to send hardware to the loading dock the same day the server powers down, which leaves no buffer for the dependency that nobody remembered. The second is misclassifying SSDs as HDDs (Step 19), then running an HDD-style overwrite tool that does not address wear leveling. The third is closing the change ticket before the certificate of destruction (Step 22) is in hand, which leaves the audit trail incomplete.

These three failure modes are easier to catch when every checklist step carries a required recordkeeping field.

For more decommission failure patterns, see ITAMG's data center decommissioning to end-user ITAD solution walkthrough.

Most server retirements hand off to an outside partner at Step 26, and that handoff moves faster when the Step 12 asset disposition manifest is already open. Bringing that manifest, with data classification and drive serials filled in, is the practical first step. It settles the sanitization method per drive, the certificate format, and the chain-of-custody fields before the hardware leaves the rack.

Where a retirement spans racks rather than a single box, data center decommissioning services apply the same controls at facility scale.