Your old server is a business risk, not an asset: how to tell when it is time

There is a particular kind of machine we get called about. It is seven or ten years old, it sits in a cupboard or under a desk, it holds the files and often the software the whole business runs on, and it has been completely reliable. Because it has been reliable, it is never on the agenda. Because it is never on the agenda, nobody has thought about what happens when it fails.

Meanwhile the accounts still treat it as an asset. It appears as a thing the business owns. That framing is the problem, because at some point in its life a server stops being something you own and becomes something you are exposed to, and there is nothing on any balance sheet that marks the moment it crossed over.

You do not need a technical assessment to work this out. Most of the signs are things an owner can check in an afternoon.

One sign on its own is a note in the diary. Two or three together means the shape of the risk has changed, because the failure modes now overlap. An out of warranty machine with no tested backup and nobody who knows how it was built is not a machine with a small chance of an inconvenience. It is a machine with a real chance of an event the business has to trade through blind.

The way to size it is not with industry figures, which will not match your business anyway. It is with two questions you can answer yourself. If that server died this morning, how many days would it take to be working normally again, honestly, including finding hardware, rebuilding, restoring and testing? And what does a day of not being able to work cost you, in wages standing idle, orders not taken and customers not served?

Multiply the two. That is your exposure, and it is usually the number that makes the decision obvious. Most owners find that the cost of the thing they have been putting off is smaller than the cost of a couple of bad days.

The default advice is to move everything to the cloud, and sometimes that is right. It is not always right, and being told it is always right is usually a sign that someone is selling rather than advising.

Cloud tends to suit you when your team is spread across homes and sites, when demand moves up and down, when you would rather pay monthly than buy hardware, and when the applications you use are happy there. Keeping something on your own premises tends to make sense when you move very large files all day, when a piece of specialist or older software will only run locally, when your connection is not strong enough to carry the whole business, or when a regulator or a customer contract requires it.

Very often the honest answer is a mix: email and documents in the cloud where they already work well, and one properly specified local machine for the specific job that needs to be local. What matters is that whatever you keep is supported, monitored, backed up in more than one place, and understood by more than one person.

The fear that keeps businesses on ageing servers is not really about cost. It is about the migration going wrong, and that fear is reasonable, because migrations done badly are genuinely disruptive.

The answer is rehearsal. A server holds live data that changes by the minute, applications with fiddly configuration and dependencies nobody wrote down. Doing the move for the first time on the night, with the business waiting, is how people lose data or discover a licence will not activate in the new environment. Doing it first on a copy, proving it works, and only then touching anything real, is what turns a leap of faith into a scheduled task.

In practice a sensible move looks like this: build the new environment, migrate onto a copy, test the applications properly with the people who actually use them, agree in writing what would make you roll back, then cut over outside trading hours with the old machine kept intact and ready as a fallback for a while afterwards. Done that way, most staff arrive to the same screens they know, working faster, with nothing to relearn.

Sometimes the timing genuinely is not right, and that is a legitimate answer. In that case, reduce the exposure rather than ignore it.

Get a second copy of everything off the machine and off the premises. Test a restore so you know the copy is real. Write down how the server is configured and what depends on it, in enough detail that someone else could rebuild it. Find out now whether replacement parts still exist, so you are not discovering that during an outage. And set a date, an actual date, to revisit the decision rather than letting it drift for another year.

If you want a straight second opinion on where a particular machine sits, we will look at it and tell you plainly whether it needs replacing now, needs watching, or is fine for another couple of years. Sometimes the useful answer is that it can wait, and we would rather say so.