Ask ten IT shops when they refresh servers and most will say "every five years" without a second thought. Ask why five, and the answers evaporate. It's not a failure statistic. It's not a workload threshold. It's a depreciation schedule that escaped from the finance department and got mistaken for an engineering fact.

The five-year refresh is a convenient fiction. Convenient because it turns a hard judgment call into a calendar entry. Fiction because hardware does not read the calendar.

Where the number came from

Five years is the standard capital-depreciation window for IT equipment under most accounting conventions. The asset is fully written down at year five, so from a balance-sheet perspective it has stopped mattering. Finance is happy to replace it because the new box becomes a fresh capital asset to depreciate.

None of that has anything to do with whether the hardware still works. A fully-depreciated server with healthy drives, adequate RAM, and a workload it handles comfortably is not a liability. It's free compute you've already paid for.

What actually predicts failure

Hardware failure follows the bathtub curve, not a line. Early life has a spike of infant mortality — the DOA drive, the bad DIMM, the PSU that dies in week three. Then a long, flat middle where well-cooled, stable gear runs for years with very low failure rates. Then a rising tail as mechanical parts wear and capacitors age.

The flat middle is longer than five years for most enterprise hardware kept in a decent environment. The components that actually age out are predictable:

  • Spinning disks — the clearest wear item. Drives have a real duty cycle and a rising failure rate past five to seven years. This is the single best argument for a refresh, and it's also the cheapest thing to replace without replacing the whole server.
  • Power supplies and fans — mechanical, they wear. But they're field-replaceable, so again, not a whole-box reason.
  • Capacitors on the board — the genuine whole-unit ager. Electrolytic caps dry out over years of heat cycling. This is what eventually takes a motherboard, and it's not economically repairable.
  • Batteries — RAID cache batteries, BMC/iDRAC/iLO batteries — cheap, wear out, easy to miss.

Notice that most of these are repairable at the part level. The thing that makes a server genuinely end-of-life is when the un-repairable parts (board, backplane) start failing, or when the cost of keeping it fed with parts exceeds its value.

The signals that actually say "replace"

Forget the calendar. These are the real triggers, roughly in order of honesty:

  1. The workload outgrew it. The box is maxed on RAM, CPU, or IO and the application is suffering. This is the only reason that's about capability rather than reliability, and it's the best reason there is.
  2. Rising correctable errors. ECC memory logging a growing rate of corrected errors, drives logging reallocated sectors, the BMC reporting thermal events — these are the machine telling you the tail of the curve has started.
  3. The failure outlook crossed your risk line. Past end-of-service-life, with no vendor firmware for a CVE that matters, and a failure that would hurt — that's a replace, and it's a risk decision, not an age decision.
  4. Power and cooling math flipped. A newer box doing the same work at half the watts can pay for itself in a dense rack. Run the actual numbers; sometimes they favor replacement years before failure would.
  5. Parts are drying up. When sourcing a replacement PSU or DIMM for the platform gets hard or expensive, the economics of keeping it alive degrade fast.

The signals that say "keep it"

Equally important, because "keep it" is usually the cheaper, lower-risk answer:

  • It handles its workload with headroom.
  • Correctable error rates are flat and low.
  • It's a role where a failure is survivable — a secondary, a lab box, a cold standby, something clustered.
  • Parts are cheap and available on the secondary market.
  • The replacement cost plus migration risk exceeds the expected cost of just running it and replacing parts as they fail.

A server in that state at year seven is not a problem. It's a well-run asset.

What to do instead of a calendar

Replace the five-year rule with a two-part discipline:

Monitor the wear items. Pull SMART data, ECC logs, and thermal history. A box telling you it's healthy gets to keep running. A box logging a rising error rate gets scheduled for replacement regardless of its age — including if it's only three years old.

Decide per-box on role and risk, not per-fleet on age. The production database primary and the backup DNS resolver do not deserve the same refresh logic. Tie the decision to what a failure of that box would actually cost.

The five-year refresh survives because it's easy, and because vendors and finance both quietly benefit from it. The operator who keeps the lights on benefits from the harder, truer answer: replace hardware when the hardware, the workload, or the risk tells you to — and let the calendar mind its own business.