An inventory shows a server in the data centre that nobody will authorise switching off. It has no documented owner and no obvious traffic. Why is this so common and how do you resolve it without an outage?

The trigger

Someone asks for a decommission approval and no one will give it. The cost of saying yes is unbounded - if the machine turns out to matter, that person caused an outage - and the cost of saying no is a line on a budget nobody is measured against. The incentives alone explain the stalemate, with no technical cause required.

Why it propagated

Three mechanisms keep these machines alive for years:

• Low-frequency dependencies. A quarterly report, an annual regulatory extract, a batch that runs on the first working day of the month. Looking for traffic over a week finds nothing and proves nothing, which is the trap in most decommissioning projects.
• Indirect use. It may hold a DNS entry, a certificate, a cron job that writes a file another system reads, a licence server, or an outbound IP allow-listed by a partner. None of these appear in an inbound traffic graph.
• Ownership decay. The team was reorganised, the service was renamed, and the only person who knew has left. Nothing is written down because it was obvious at the time.

Why detection lagged

Because nobody asked the question in a form that could be answered. "Does anyone use this?" has no evidential answer. "Has anything connected to this machine in the last 90 days, and from where?" does, and almost no estate collects it until someone wants to turn something off.

The structural fix

• Collect connection evidence before you need it. Flow logs or connection accounting on every host, retained for at least 13 months so an annual job is inside the window. This is the single highest-value piece of decommissioning infrastructure and it costs almost nothing.
• Use a quiet period plus a deliberate denial, not a guess. Announce the date, then block traffic rather than powering off - firewall it, return an error, or stop the service while the host remains - for a defined period. Something that breaks is now a fast, reversible failure instead of an unrecoverable one, which is the whole point.
• Keep the data, retire the machine. Snapshot the disks, export the database, record the configuration, and keep that archive for the retention period. Most objections are about data, not compute, and separating them removes the objection.
• Make an owner mandatory for existence, with a quarterly confirmation. An asset with no confirmed owner is scheduled for the quiet-period process automatically.
• Give the approver cover. A documented procedure with a named rollback and a time-boxed quiet period converts an unbounded personal risk into a process, which is what actually unblocks the decision.

The general lesson

Decommissioning is an evidence problem disguised as a technical one. The machine is not hard to turn off; the difficulty is that nobody can prove it is safe, and proof requires data that was never collected. Collect it as a habit, run every retirement as a reversible denial rather than a one-way power-off, and the stalemate never forms.

When not to spend effort here

One idle virtual machine costs tens of pounds a month and the process above costs more than that in meetings. Run it when the estate has dozens of candidates, when a licence or support contract is priced per host, or when an audit requires an accurate asset inventory - and in the meantime, tag the machine as unverified and move on. The exception is security: an unowned host that is also unpatched is a live risk rather than a cost, and that justifies the work on its own.