Turning off a server is the step where things get forgotten, because the pressure is gone: the work has moved, nobody is waiting, and the machine sits there costing money until somebody cancels it. Then it is cancelled quickly and something turns out to have still been on it.
Find out what is actually on it
Before anything, inventory the machine rather than trusting your memory of it.
Sites and their document roots. Databases. Mailboxes. Cron jobs and what they do. Anything listening on a port. Any DNS zone the server answers for.
Servers accumulate: a staging copy of a site that moved, a small tool somebody wrote, a nightly job emailing a report to a client. Those are exactly what gets lost. How to Schedule Jobs with Cron and Systemd Timers walks through finding scheduled work in the several places it hides.
Check what is still pointing at it
An address that still resolves to the server is something that will break when it stops.
Look for DNS records (A, MX, and any subdomain) still aimed at this machine, including ones on domains you are not thinking about. On a DNS cluster, check every member in place of the one you are logged into: a zone left on a member keeps answering for a domain you no longer host. Setting Up and Maintaining a DNS Cluster walks through removing them.
Then check the reverse: is this server's address in someone else's SPF record, in an API allow list, in a firewall rule elsewhere?
Watch the traffic before deciding it is idle
The check that finds what the inventory missed.
Leave the server running and watch the access and mail logs for a week. Anything still arriving is something still using it: often a client's cron job, a monitoring service, or a third party integrating with a URL nobody documented.
A server that receives nothing for a week is genuinely idle. One that receives a request a day is not, and that request is exactly what you would otherwise break.
Take a final backup, and keep it longer than feels necessary
Full backup, downloaded and verified: not a snapshot on the same platform, which disappears with the server.
Keep it for a year. The thing you need turns up months later: a file, a database row, an invoice, an email. Storage is cheap and the machine will not be there to ask.
Verify it opens rather than assuming. An archive that will not extract is not a backup, and this is the last moment you can discover that. There is more on where it should live in Backups and Disaster Recovery for Dedicated Servers.
Deal with the data properly
Personal data on a decommissioned server is still your responsibility until it is gone.
For a dedicated server, ask the provider what happens to the disks: whether they are wiped, to what standard, and whether they will confirm it. For a VPS, the volume is usually reclaimed and reused, and encryption at rest is worth having had rather than requested at the end.
If the machine held anything sensitive, wipe what you can before releasing it rather than relying on the provider's process, and note that on a virtual machine you cannot be certain of what the underlying storage does.
Move mail last, and keep receiving
If the server handled mail, messages continue arriving after you think you have moved.
Senders holding the old MX record keep delivering there while caches expire, and some retry for days. Keep mail working on the old machine for at least a week after the change, then check the mailboxes one final time before shutting it down. How to Migrate Email to a New Host explains the sequence.
Turn it off before you cancel it
The step that makes the whole thing reversible.
Shut the server down and leave it shut down for a week or two while still paying for it. Anything that depended on it fails now, while the machine can still be started.
That is a much cheaper way to discover a dependency than cancelling and finding out. Then cancel once the quiet period has passed.
Close the account side properly
Cancel the billing at the provider rather than only stopping the payment, and get confirmation.
Then remove the machine from everything that references it: monitoring, backup jobs pointing at it, deployment configuration, firewall allow lists, and any documentation that tells someone it exists.
A monitor still watching a decommissioned server alerts forever, and alerts that are always wrong are how people learn to ignore alerts.
Write down that it is gone
What the server was for, when it was decommissioned, where the final backup is, and what moved where.
Six months later, "what happened to the old server" is a question somebody will ask, and the answer being written down is the difference between a sentence and an afternoon.
What happens to the hardware at the end depends on whether you own it. Colocation Versus Rented Dedicated Hardware walks through that difference.
Reclaim the licences and the addresses
Decommissioning frees more than a machine, and the parts that are not the machine are the ones that keep being charged for.
/usr/local/cpanel/cpkeyclt --status 2>/dev/null
ip -4 -o addr show scope global | awk '{print $2, $4}'
crontab -l | grep -iE 'licen|activat' | head
Panel licences, monitoring agents, backup services and any per server subscription are usually billed separately from the machine and continue after it is gone.
Addresses matter for a second reason. An address released back to the provider is reassigned to somebody else, and anything still pointing at it now points at a stranger's server. Confirm nothing references it before the release, not after.
Remove the machine from everything that watches it
A decommissioned server that is still monitored produces alerts forever, and the usual response is to stop reading the alerts.
ssh-keygen -R old.example.com grep -rn 'old.example.com' ~/.ssh/config /etc/hosts 2>/dev/null grep -rln 'old.example.com' /etc/ 2>/dev/null | head
Work through the list deliberately: monitoring checks, backup jobs pointed at it, log shipping, configuration management, the entries in colleagues' connection files, and any deployment that names it.
The one people miss is a backup job on another machine that pushes to this one. It keeps running, keeps failing, and the failure is buried among alerts nobody reads any more because of the first problem.
Prove the data is gone rather than assuming
Handing a machine back means handing back whatever is on the disks, and the provider's wipe is their process rather than yours.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT find / -xdev -name '*.sql' -o -xdev -name '*.tar.gz' 2>/dev/null | head
Where the machine held anything sensitive, the useful step is destroying the keys rather than the data. An encrypted volume whose key is deleted is unreadable regardless of what happens to the disks afterwards, and that is verifiable in a way that a promised wipe is not.
Record what you did and when. A year later, the question of whether a particular server held customer data and what became of it is one somebody will ask, and the answer needs to be a note rather than a recollection.