Server Decommissioning Checklist

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.