When to refresh hardware

Hardware refresh decisions are usually made on age, because age is the easiest thing to measure. A three-year or four-year cycle is applied uniformly, and equipment is replaced whether or not replacement was warranted.

That approach is simple and it is wrong in both directions. It replaces machines that were fine and keeps machines that are costing more than they save.

The three things actually worth balancing

Warranty and support

The clearest signal, because it changes the cost of failure rather than the probability.

Under warranty, a failure is a call and a replacement part, usually within an agreed timeframe. Out of warranty, it is a procurement exercise with an uncertain timeline, or a spares cupboard you have to fund and maintain.

Extended warranty is available but the price rises each year, and at some point the extension costs a meaningful fraction of replacement. That crossover point is worth calculating rather than assuming.

The related question is parts availability. Manufacturers stop producing parts for older models. When the constraint becomes availability rather than cost, the risk is no longer manageable by spending more.

Performance against what the work now requires

Hardware does not slow down. The demands placed on it grow.

For endpoints, the relevant measure is time lost. A machine where the operating system, security tooling and business applications together consume most of the available memory produces daily friction: slow starts, slow switching, occasional freezes. Each instance is small; across a year and a workforce it is substantial and it is entirely invisible on any report.

The practical test is not benchmark scores. It is whether users are waiting, and whether the machine can run what the business now needs it to run. Security tooling in particular has grown significantly heavier, and it is often the change that makes an otherwise adequate machine unusable.

The cost of failure

This is what distinguishes one machine from another and what the uniform cycle ignores completely.

A laptop failure for an office-based employee with a spare available is an inconvenience of an hour or two. The same failure for someone travelling, or on a critical deadline, or at a site with no spare, is a day or more.

For servers and network equipment the range is wider still, from unnoticed to business-stopping.

Refresh priority should follow this, not the purchase date. Equipment where failure is expensive should be replaced earlier; equipment where failure is cheap can run considerably longer.

A better approach than a fixed cycle

Segment by consequence. Three tiers is usually enough: equipment where failure stops something important, equipment where failure is disruptive, and equipment where failure is an inconvenience.

Set a different policy per tier. The first tier is replaced while under warranty, without argument. The second is replaced at warranty expiry unless there is a reason not to. The third runs until it fails or becomes unusable, with a spares pool to cover it.

Track the signals, not just the date. Support tickets per device, warranty status, whether it can run the current standard build, and predictive hardware indicators where available. A device generating repeated tickets is telling you something the calendar cannot.

Keep a spares pool for the lowest tier. Replacing on failure only works if replacement is immediate. A modest pool of standard-build machines makes it work and is cheaper than early replacement across the fleet.

What the fixed-cycle approach gets right

It is worth acknowledging why fixed cycles persist, because the reasons are real.

Budget predictability. A known annual replacement cost is easier to plan than a variable one, and finance departments value that.

Fleet standardisation. Replacing in batches keeps the estate on a small number of models, which simplifies support, imaging and spares.

Procurement leverage. Larger, predictable orders get better pricing.

The compromise most organisations land on is a fixed budget with flexible allocation: a known annual spend, but the choice of what gets replaced driven by tier and condition rather than by purchase date.

Signals that a device should go now

Regardless of age:

• It cannot run the current standard build, including security tooling, without noticeable degradation.
• The operating system or firmware is past end of support and cannot be upgraded.
• It has generated repeated hardware-related tickets.
• Parts are no longer readily available.
• The extended warranty cost is approaching a significant fraction of replacement.
• Predictive indicators (drive health, correctable memory errors) are trending badly.

Any two of these together is usually a clear case.

Signals that it can stay

• Under warranty, no faults, running the current build without complaint.
• Failure is cheap, and a spare is available.
• The role it performs is being retired within a defined period.

What to do with what you replace

Two things that are often handled poorly.

Data destruction. Every device leaving your control needs its storage wiped or destroyed to a standard you can evidence. If you are certified or regulated, you will need certificates. Arrange this as part of the disposal process rather than as an afterthought.

The register. Disposal is where asset registers lose accuracy fastest, because equipment leaves quietly and nobody records it. Make the disposal record a required step, with a date and method, or next year's inventory will be wrong in the same way this year's was.