Most of this site nudges, gently, toward replacement. The math usually points there. The vendor's roadmap points there. The salesperson definitely points there.

But not always. And the days when it points the other way are the days that take real discipline to honor.

This article is the brand's honest counterweight. The case for keeping it.

What the vendor is not telling you

The 5-year hardware refresh cycle is not an engineering finding. It is a sales convention. Vendors set it because it matches their financial models, their depreciation tables, their support contract pricing, their channel partner programs. It is not a number that emerged from data about when servers fail.

Empirical reality: a well-maintained enterprise server in a clean datacenter, on UPS power, with proper cooling, running a manageable load, regularly hits 8-10 years of useful service. Storage arrays from established vendors regularly run 7-12 years on the same hardware before the controllers are the bottleneck. Network gear, as the previous article documented, runs longer still.

The refresh cycle is a budgeting convention dressed as an engineering recommendation.

What replacement actually costs

The salesperson quotes you the gear. The capital expense is the visible number. It is the smallest number.

The real cost of a hardware refresh includes:

  • Migration risk — every replacement has a non-zero chance of an outage during the cutover
  • Retraining — operators have to learn the new management interface, the new firmware quirks, the new monitoring telemetry
  • OS revalidation — application owners have to revalidate their software stack on the new platform
  • Change management — the request for change, the approval process, the maintenance window, the rollback plan
  • Compliance re-attestation — security and compliance teams audit the new gear, re-run controls, document the new baseline
  • Documentation churn — runbooks, network diagrams, asset registers, contracts all touch the new platform
  • Spare parts inventory turnover — your shelf of spare PSUs and drives for the old gear is now useless

In a 50-server environment, the hidden cost of refresh is regularly 2-3× the hardware purchase. The vendor will not mention this. They are not lying; it just is not their cost.

When keeping is actually right

Five conditions. If most of them are true, the right answer is probably maintain, not replace.

The workload has not grown past the platform. The CPU is not pegged. Memory pressure is acceptable. Disk IOPS are within tolerance. The platform is doing what it was bought to do, and the demand on it has not materially changed.

Power efficiency is not crossing an operational threshold. Power and cooling efficiency has improved since the hardware was bought, but you are not facing a datacenter power constraint that makes the inefficiency matter. The OPEX hit of running older gear is real but small enough to absorb.

End-of-software-support has not passed. Critical: the vendor is still shipping security patches. If they have stopped, the calculus changes entirely (see below).

Staff has the capacity to maintain. Someone on the team can swap a PSU at 11pm without panic. Spare parts are available on the secondhand market or via a third-party-maintenance contract. The institutional knowledge to run this generation of the platform has not left.

The replacement does not solve a problem you currently have. This is the most overlooked condition. Refresh-driven replacement does not improve uptime, security posture, or capacity until the workload requires it. Replacing healthy gear because it is old is a wasted cycle.

When keeping is wrong

The four conditions that flip the answer.

The workload has grown past the platform. CPU saturation during business hours. Memory pressure causing thrashing. Disk IOPS bottlenecking the application. You cannot grow your way out of an undersized platform; you have to refresh.

End-of-software-support has passed. Once the vendor stops shipping security patches, every CVE that lands against the platform is an open exposure with no defensible fix. Compensating controls (network segmentation, IDS rules, virtual patching) help but do not close. A 10-year-old server on a current OS with current security patches can be defensible. A 5-year-old server on an EOL platform with no patches is not.

The team that can maintain it has left. The engineer who knew the storage array's quirks moved on. The runbook references commands no one on the current team recognizes. The vendor's documentation has been archived behind a paywall. When the maintenance knowledge has decayed below the threshold needed to handle a real failure, you have already committed to replacement; the only question is whether you do it on schedule or under emergency.

Compliance has shifted. A regulator has changed the baseline. PCI-DSS v4 introduces a control your old platform cannot satisfy. HIPAA changes the encryption-at-rest expectation. The platform was compliant in 2018 and is not in 2026. Maintenance cannot fix this.

The discipline of keeping

Honoring the case for keeping requires real operational discipline:

  • A written hardware register, updated quarterly, with each asset's current support status
  • A documented runbook for each platform that hasn't been refreshed, kept current as staff turn over
  • A stocked spare-parts shelf or a third-party-maintenance contract on the gear you have committed to keeping
  • A scheduled annual review where each "we are keeping this" decision is re-examined
  • A clear list of the conditions that would trigger refresh, written down so it is not relitigated every quarter

Without this discipline, "keeping it" becomes drift. Drift means a server still in the rack because nobody felt like decommissioning it, running a workload nobody documented, on firmware nobody knows is current. That is not keeping; that is neglecting.

The Bushido virtue at the center of this

The Bushido Code names seven virtues. Two of them speak directly to this article.

Yu (勇), courage. The willingness to defend a still-capable machine against the easy sale. The vendor's quote arrives, the budget is approved, the path of least resistance is to buy the new gear. Saying "this works and we are keeping it" requires courage in the room because it is the unexpected answer.

Jin (仁), benevolence. Caring for the gear others have abandoned. The vendor has moved on. The sales cycle has shifted. The machine still serves the user faithfully. Choosing to care for it — to keep it running, to feed it patches, to stock its parts — is an act of stewardship.

The Zen of TPM is not in any contract. It is in the clarity of the decision before the contract.

The right hardware decision is sometimes "buy new." Sometimes it is "renew the OEM contract." Sometimes it is "TPM it for half the price." And sometimes — more often than the vendor would tell you — it is "keep it, maintain it, do not change the thing that is working."

That last one takes the most discipline. It is also, sometimes, the wisest answer.