There is a particular kind of system that exists in almost every organisation we have ever worked with.
Nobody is quite sure what it does. Nobody is quite sure who uses it. It has been running for years — maybe a decade — and at some point, the person who set it up left. The documentation, if there ever was any, is gone. It just sits there, quietly consuming resources, and everyone agrees without saying so that the safest thing to do is leave it alone.
But there is a problem lurking here, and it has at least three dimensions.
If it eventually breaks, you have no idea what to do.
You do not know what it does, so you do not know what is affected. You do not know who relies on it, so you cannot notify anyone. You do not know how it was configured, so you cannot restore it. What should be a routine incident turns into a crisis with no clear owner and no clear path forward.
The longer a system runs unexamined, the worse this gets. Every year without documentation is another year of institutional knowledge that exists nowhere except in the system itself — and systems do not answer questions.
If it does not do anything useful, you are wasting resources.
Compute costs money. Licences cost money. Maintenance windows cost money. Every system in your environment is something that has to be patched, monitored, backed up, and kept alive. If nobody can tell you what value a system provides, the probability that it provides any is low.
More importantly: complexity costs money too. Every system your engineers have to work around, every dependency that has to be accounted for, every integration that has to be preserved just in case — it all adds friction to everything else.
If it is old software, security is not an abstract concern.
Unpatched systems are not just a risk on paper. They are an open invitation. Old software often carries known vulnerabilities that have been publicly documented for years. Attackers do not need to be sophisticated to exploit them — they just need to find them, which automated scanning tools do continuously.
A system you are afraid to touch is almost certainly a system you are also afraid to patch. And a system that has not been patched is a system that is waiting to be exploited.
The Simplest Thing You Can Do: Turn It Off.
Not delete it. Not decommission it immediately. Just turn it off.
Before you do, make sure you can turn it back on quickly if something breaks. Note the time. Then pull the switch.
What happens next will tell you more than any audit ever could.
In most cases: nothing happens. No one calls. No alerts fire. No process fails. The system was running, but it was not doing anything. You have just freed up resources, reduced your attack surface, and simplified your environment — all at once.
In some cases: something does happen. A process fails, a user complains, a monitoring alert fires. Now you know it matters, and you know its users. You turn it back on, you document what you found, and you start planning a proper migration or replacement.
The uncomfortable truth is that the only way to find out whether a system is actually used is to stop running it. Every other method — surveys, dependency mapping, log analysis — is useful, but incomplete. Logs only capture what has happened recently. Surveys only capture what people remember. Turning something off captures reality.
We do this regularly as part of our engagements. The number of systems that turn out to be genuinely unused is consistently higher than clients expect. The number of surprise dependencies that only surface when something goes dark is also, consistently, higher than clients expect.
Both findings are useful. Both are only possible because something was switched off.
If you have systems in your environment that nobody dares touch, that is exactly where to start. Talk to us.