Server Decommissioning Checklist

Steps a sysadmin or infrastructure engineer follows to retire a physical or virtual server, from stakeholder notification and dependency mapping through data sanitization, asset disposal, and post-mortem documentation.

6 sections 24 steps Collects data
1

Discovery and Dependency Mapping

  1. Identify the server and capture its CMDB record
    • Pull the asset record from ServiceNow, IT Glue, Hudu, or whichever CMDB is source of truth. Capture hostname, FQDN, IP addresses, rack location (or hypervisor cluster), serial number, asset tag, and warranty status. Cross-check against RMM (Datto, NinjaOne, ConnectWise Automate) — orphan agents are a common discovery gap.

    Collects text Collects text Collects list
  2. Map running services and listening ports
    • Run netstat -anob (Windows) or ss -tlnp (Linux), pull recent NetFlow from the firewall, and review SCOM/PRTG/LogicMonitor service checks. Flag scheduled tasks, cron jobs, IIS sites, SQL instances, and any service accounts authenticating against this host.

  3. Identify upstream and downstream dependencies
    • Trace what consumes this server (load balancer pools, application config files, DNS CNAMEs, hardcoded IPs in scripts) and what it consumes (databases, file shares, API endpoints). Hardcoded references in legacy apps are the #1 cause of post-decommission outages.

  4. Confirm whether workloads need migration
    Collects list
  5. Document the migration target and cutover plan
    • Capture the destination host, IP plan, DNS changes, firewall rule updates, and rollback procedure. Required when workloads are migrating; skip if the server is being retired outright.

2

Change Approval and Communication

  1. Submit the change request to CAB
    • File the RFC in ServiceNow / Jira Service Management with maintenance window, blast radius, rollback plan, and named approver. Server decommission is normal change, not standard — CAB review is required even for low-utilization hosts.

    Collects text
  2. Notify application owners and end users
    • Send the formal notice 14, 7, and 1 days before cutover. Include hostname, services affected, migration target (if any), and a named contact. Skipping the 1-day reminder is how a quiet server gets noisy on decommission day.

  3. Confirm compliance and data-retention obligations
    • If the server hosts PHI, cardholder data, SOX-relevant records, or anything under legal hold, coordinate with security/legal before sanitization. PCI DSS 9.8 and HIPAA Security Rule 164.310(d)(2)(i) both require documented destruction of media that held in-scope data.

3

Backup and Snapshot

  1. Take a final full backup
    • Run a final Veeam, Datto, or Commvault backup outside the normal schedule and tag it with extended retention per the data retention policy. For VMs, take a snapshot in addition to the backup; for physical hosts, image the disk with Clonezilla or vendor tooling.

  2. Test-restore a sample to confirm backup integrity
    • Restore at least one file or database to an isolated location and confirm it opens. A green backup job that has never been restored is not a backup — it's a hope. This is the last chance to discover the backup is unusable.

    Collects file
  3. Export configuration and secrets to the vault
    • Capture IIS / Apache / nginx configs, scheduled task XML, registry exports, SSL certificates, and any local service account credentials into Keeper, 1Password, Hudu Vault, or IT Glue. Document where each secret lives so it survives the host going dark.

4

Decommission Execution

  1. Stop services and disable scheduled tasks
    • Set Windows services to Disabled (not just Stopped) so a reboot doesn't bring them back. Disable cron and systemd timers on Linux. Stop any clustered services through the cluster manager, not the local service control.

  2. Remove DNS records and load balancer pool members
    • Pull A/AAAA/CNAME records, F5 / NetScaler / Azure LB pool members, and any reverse-proxy upstreams. Lowering TTL 24 hours in advance makes this a clean cutover instead of a stale-cache incident.

  3. Disable the AD computer object and service accounts
    • Disable — do not delete — the computer object in Active Directory / Entra ID and move to a Decommissioned OU. Rotate or disable any service accounts the host owned. Wait 30 days before deletion in case rollback is needed.

  4. Disconnect from the network and remove monitoring
    • Disable the switch port (or remove the VM's vNIC), then uninstall RMM, EDR (CrowdStrike, SentinelOne, Defender), backup agent, and monitoring agents (PRTG, LogicMonitor, Datadog). Orphan agents continue billing and clutter dashboards.

  5. Hold the soak period to surface missed dependencies
    • Leave the server powered off but recoverable for at least 14 days. This is the window in which a quarterly job, monthly report, or hardcoded script will fail loudly and let you fix the dependency before media destruction makes rollback impossible.

    Collects list
  6. Restore the server and reopen the dependency ticket
    • Power the host back on, re-enable network and monitoring, file a follow-up ticket against the dependency owner, and restart this checklist when the dependency is resolved. Better one false start than a six-figure data-loss incident.

5

Media Sanitization and Disposal

  1. Sanitize storage media per NIST SP 800-88
    • Apply Clear, Purge, or Destroy per NIST SP 800-88 Rev 1 based on data classification. SED drives accept ATA Secure Erase / cryptographic erase; non-SED drives need overwrite or physical destruction. SSDs almost always require Purge or Destroy — overwrite alone is not sufficient.

    Collects list Collects file
  2. Remove the host from the rack or hypervisor
    • For physical: pull the host from the rack, label it for disposition, update the rack elevation diagram, and reclaim the U-space. For VMs: delete from inventory after the soak period and reclaim the datastore space. Update PDU and cable mappings in either case.

  3. Hand off hardware to certified e-waste vendor
    • Use an R2v3 or e-Stewards certified ITAD vendor (Iron Mountain, ERI, Sims Lifecycle Services). Collect chain-of-custody manifest with serial numbers and certificate of destruction. Required evidence for SOC 2, PCI DSS, and most state data-privacy laws.

    Collects file
6

Closeout and Documentation

  1. Update CMDB and asset management records
    • Mark the asset Decommissioned in ServiceNow / IT Glue / Hudu with disposal date, sanitization certificate, and CR number. Reclaim the license entitlement (Windows Server CAL, SQL Server core licenses, monitoring agent slot) so the next vendor audit doesn't surface ghosts.

  2. Reclaim software licenses and renewals
    • Walk the application list from the discovery phase: Microsoft, VMware, Veeam, antivirus, monitoring. Cancel autorenewals tied to this hostname; reassign perpetual licenses where transferable.

  3. Close the change ticket with evidence
    Collects list Collects paragraph Collects signature
  4. Run a brief post-mortem with the team
    • 15-minute review with the change owner and any responders who hit dependency surprises during soak. Capture what discovery missed and feed it back into the next decommission's checklist — this is how a runbook gets sharper over time.

Use this template

Copy it to your account, customize the steps, and run it with your team in minutes.


Sections 6
Steps 24
Category Systems Administration
Price Free to start
Need a different process

Browse hundreds of free templates across every team and industry.

Back to template library

Run Server Decommissioning Checklist with your team

Customize the steps, assign roles, set a schedule, and keep a complete record for every run.