The box in the corner that nobody touches
Somewhere there is a server that runs something important: the old intranet, the accounts integration, a line-of-business application, maybe the main website. It is running Windows Server 2012, CentOS 7, an old Ubuntu release, or something older. It has been up for a very long time. Nobody wants to restart it, let alone upgrade it.
The vendor stopped issuing security updates for that operating system a while ago. Your IT provider has mentioned it in a couple of reports. A customer's security questionnaire asked about it, and the honest answer was uncomfortable.
Why old servers linger
- It works, and nobody wants to disturb something that works.
- Nobody fully knows what is installed on it or what depends on it.
- The application on it needs an old runtime or library that the new OS does not include.
- It was built by hand years ago, so rebuilding means rediscovering every setting.
- Upgrading in place looks risky, and a clean rebuild looks like a big project.
The lack of knowledge is the real blocker. The upgrade itself is ordinary work. Working out what the server is really doing is where the time goes.
The risk of leaving it
| Risk | Why it matters |
|---|---|
| Unpatched vulnerabilities | Every new flaw published for that OS stays open on your server permanently |
| Attack path into other systems | A compromised old server is a foothold into the rest of your network or cloud account |
| Software support ending | Newer versions of databases, runtimes and agents stop supporting the old OS |
| Hardware or host retirement | Cloud providers and hosts phase out old images and instance types |
| Customer and insurer questions | Security questionnaires and cyber insurance often ask about unsupported systems |
| Single point of failure | If it dies, rebuilding from scratch under pressure is very hard |
The attack path row is worth taking seriously. The old server may not hold anything valuable itself, but it often has network access and stored credentials for things that do.
How we move you off it
- Take a full backup and snapshot first, and confirm it restores, so nothing we do can make things worse.
- Discover what it does. We list installed software, running services, scheduled tasks, open ports, network connections, file shares, certificates and the applications that talk to it.
- Contain the exposure straight away: close unneeded ports, restrict network access to what is necessary, and rotate credentials stored on it.
- Choose the target. Often this is a supported OS on a fresh cloud server or virtual machine, sometimes a managed service (a managed database instead of one on the server), sometimes containers.
- Rebuild with repeatable configuration, using scripts or tools such as Ansible or Terraform, so the new server can be recreated rather than hand-crafted again.
- Move applications and data across, update any old runtimes or libraries they need, and test them on the new server with the people who use them.
- Cut over with a rollback plan, keep the old server available but switched off for a period in case something was missed, then decommission it.
If an application genuinely cannot run on a supported OS, we explain the options: updating the application, replacing it, or isolating the old server tightly as a temporary measure while that happens.
Running on something supported
Your applications run on a supported operating system that gets security updates, applied on a schedule. The server's setup is written down as code, so it can be rebuilt if it fails. You know what it does and what depends on it. And the next time a security questionnaire asks about unsupported systems, the answer is straightforward.
Does this sound like your server?
- A server runs an operating system that no longer receives security updates.
- Nobody is sure everything it does or what depends on it.
- It was set up by hand and there is no documentation.
- The application on it needs an old version of a runtime or database.
- You have been asked about it by a customer, auditor or insurer.