Hardware Refresh Policy & Replacement Cycles

Why a Written Refresh Policy Pays for Itself

A hardware refresh policy states, in advance, how long each class of equipment stays in service and what triggers its replacement. Without one, replacement is demand-driven: devices are replaced when they fail, when a user complains loudly enough, or when a project needs them gone. All three are the most expensive moments to buy hardware.

The cost of reactive replacement is rarely a single line in a budget, which is why it survives so long. It shows up as expedited shipping, list-price purchases outside framework agreements, support hours spent nursing failing machines, and productivity lost while someone waits. A policy converts that scattered, unbudgeted spend into a forecastable annual number, which is the point at which finance can plan for it and procurement can negotiate on it.

The policy is only as good as the data behind it. Age-based refresh needs an accurate in-service date on every asset; condition-based refresh needs failure and repair history. Both come out of the asset data model, and both are worthless if a third of the fleet is missing from the register.

Standard Lifespans by Asset Type

Useful life varies more by role than by hardware quality. A laptop used for email in an office lasts materially longer than an identical laptop carried daily by a field engineer. The table below gives typical enterprise refresh intervals; treat them as a starting position to adjust against your own failure data, not as a standard to adopt unexamined.

Leased equipment is the exception: its refresh date is set by the lease maturity date, not by policy. Where a fleet mixes purchased and leased assets, the policy needs an explicit ownership flag so that the two populations are planned separately — a purchased device can be extended a year, a leased one usually cannot without penalty.

Embedded and specialist systems — industrial controllers, medical devices, point-of-sale terminals, building management hardware — do not follow endpoint cycles at all. Their replacement is driven by the supported life of the platform and by regulatory recertification, and they frequently outlive three generations of laptop. Give them their own section in the policy rather than forcing them into the standard table.

Component-Level Policy: GPUs, SSDs, NICs, PSUs and Fans

Whole-device refresh is the wrong unit for servers and workstations, where individual components wear at very different rates. A hardware lifecycle policy for components sets replacement rules per part, usually based on a measurable wear indicator rather than calendar age.

Two things make component policy work in practice. First, the components have to be tracked as sub-records against the parent asset, so that a replaced drive updates a record rather than disappearing into a work order — the server and datacenter HAM guide covers that structure. Second, replacing a component may be a capital addition rather than a repair, which changes the depreciation schedule; the depreciation guide covers where that threshold sits.

Refresh Triggers Beyond Age

Age is the default trigger because it is the easiest to plan around, but it is rarely the best predictor of when a device should actually go. A mature policy lists several triggers and refreshes on whichever fires first.

• Warranty or support expiry. The point at which a failure stops being a phone call and starts being a purchase. For servers and network gear, vendor support renewal cost often exceeds replacement cost, and that crossover is the real refresh date.
• Vendor end-of-support for the platform. A device that can no longer receive security updates is a compliance problem regardless of how well it runs, and it will be raised as a finding — see the compliance guide.
• Accumulated repair cost. A standing rule such as "replace when cumulative repair cost since purchase exceeds 40% of replacement cost" catches lemons that age-based policy would keep for another two years.
• Repeat incident count. Three or more hardware-caused incidents in twelve months is a stronger signal than age, and the data already exists in the service desk.
• Battery health. For laptops and phones, the practical end of life is usually the battery. Below 70% design capacity, the device is either tethered or replaced.
• Role change. Moving a user from office to field, or from general to specialist work, may require a different device before the current one is due.
• Lease maturity. Non-negotiable for leased assets; the return date is the refresh date.

Cutting Emergency Hardware Spend

Emergency hardware spend is what a missing refresh policy costs, and it is usually visible in the data before anyone names it. Three signals identify it: a high proportion of purchases made outside framework pricing, short intervals between request and required-by date, and a repair backlog concentrated in devices past their nominal life.

Reducing it is a sequencing problem rather than a savings exercise:

1. Establish the age profile. Chart the fleet by in-service year. If a large share sits past its nominal life, the emergency spend is not bad luck — it is a queue of deferred replacements arriving one failure at a time.
2. Forecast the next twelve months. Devices reaching their trigger date in the coming year, by quarter and by cost centre. This is the number that turns replacement into a budget line.
3. Buy in planned batches. Batch purchasing at framework pricing with normal lead times is materially cheaper per unit than expedited single-unit purchases, and it lets images and builds be prepared in advance.
4. Hold a buffer pool. A small stock of standard-configuration devices — commonly 2–3% of the fleet — absorbs genuine emergencies without an expedited purchase. Refreshed devices returning to stock keep the pool current.
5. Clear the backlog deliberately. If a large share of the fleet is already overdue, spread the catch-up across two or three budget cycles rather than accepting another year of failures.

The buffer pool depends on the return loop actually working. Devices recovered from leavers and role changes need triage, wipe, and rebuild before they count as available stock — the request and procurement guide covers that return path and the stock check that consumes it.

When Extending a Lifecycle Is the Right Call

Extension is a legitimate decision, not a failure of the policy — provided it is a decision rather than a drift. The clearest case is fixed-role, low-demand hardware: call centre and shared workstations doing browser and telephony work place a fraction of the load of an engineering machine, sit in a controlled environment, and are never carried anywhere. Extending those from four years to six is often defensible where extending a field laptop is not.

An extension is safe when all of the following hold:

• The platform still receives vendor security updates for the full extension period.
• Support is available — either extended warranty at sensible cost, or enough spares held to self-service.
• Failure rates for that cohort are flat, not rising. A rising curve means the extension will be paid for in downtime.
• The performance envelope is not moving. A software upgrade planned for next year can invalidate an extension decided this year.
• The device is owned, not leased.

Two practices make extensions work. Replace the wear parts rather than the whole unit — a drive and a battery cost a fraction of a new machine and address most age-related failures. And extend by explicit cohort with a recorded new date, so the decision is visible, reviewable, and does not quietly become permanent.

The failure mode to avoid is extending without a spares position. A fleet kept two years past support with no stock of drives, power supplies, or replacement units converts every failure into an expedited purchase — which is exactly the spending pattern the policy existed to remove.

Writing the Policy: What It Must Contain

A refresh policy that people follow is short and specific. Six sections are usually enough:

1. Scope. Which asset classes the policy covers, and which are explicitly out (embedded systems, lab equipment, leased assets under separate terms).
2. Standard lifespans. The table, by asset class and role, with the in-service date as the reference point.
3. Triggers. The full list of refresh triggers and the rule that whichever fires first governs.
4. Exception and extension process. Who can approve an extension, on what evidence, for how long, and where the decision is recorded.
5. Funding model. Whether refresh is centrally funded or charged to cost centres, and how the annual forecast is produced and approved.
6. Disposal route. What happens to the replaced device — return to stock, redeploy to a lower-demand role, or disposal under the ITAD procedure with a certificate of destruction.

Review the policy annually against actual failure data. Lifespans set once and never revisited drift out of line with the fleet, and the first sign is usually a rise in emergency replacements in a class the policy claims is well within life.

Metrics That Show the Policy Is Working

• Fleet age distribution. Share of assets within nominal life, past it, and past it with an approved extension. The headline number.
• Planned vs unplanned replacement ratio. The direct measure of the policy's purpose. A healthy programme runs above 80% planned.
• Emergency purchase share. Percentage of hardware spend made outside framework pricing or with expedited delivery.
• Hardware-caused incidents per 100 devices. Falling as the age profile improves; a leading indicator that the lifespans are set correctly.
• Repair spend on out-of-warranty assets. Money spent keeping devices alive past their support window.
• Extension count and duration. Rising extensions usually mean the budget, not the policy, is the constraint — worth surfacing explicitly.
• Redeployment rate. Share of refreshed devices redeployed to lower-demand roles rather than disposed of.

Next Steps