Refresh Cycles and Replacement Planning

Devices get replaced either on a schedule or when they fail. Most organisations claim the first and practise the second.

The case for a fixed cycle

Predictable budget. A known number of devices each year rather than an unpredictable failure rate.

Predictable support load. Older fleets generate disproportionate support tickets.

Security. Devices out of vendor support do not receive firmware and OS updates.

Productivity. Slow machines cost time continuously and invisibly.

Residual value. Devices sold or traded at three years are worth something; at six they are worth nothing.

Warranty coverage for the whole life, avoiding out-of-warranty repair costs.

The case against

Capital cost, brought forward.

Perfectly serviceable devices replaced, which is wasteful in money and in materials.

Disruption for users who did not want a new machine.

Environmental cost, which is increasingly a stated commitment rather than an aside.

The reasonable position

A target cycle, with exceptions. Three or four years as a default, with devices assessed rather than replaced automatically.

Assess at the target date: is it still performing, still supported, still under warranty, still meeting the user's needs. Replace if any answer is no.

Extend where the answer is yes, and record the extension so it is revisited.

Replace early where the role demands it, rather than treating the cycle as a ceiling.

This is more work than a fixed cycle and less wasteful, and it requires the register to hold the data that makes assessment possible.

The data the decision needs

Age, from purchase date.

Warranty status.

Vendor support status for the model and for the operating system it can run.

Support ticket history for that asset.

Performance, where endpoint management reports it.

Role, since requirements differ enormously.

Most of this is already in your systems and unjoined, which is what makes refresh planning feel like a project.

Budgeting it

Model the fleet by age. How many devices reach the target this year, next year, the year after.

Smooth the peaks. A fleet bought in one large batch reaches refresh in one large batch, which is a budgeting problem you can anticipate years ahead.

Include accessories in the plan, since monitors and docks have their own lives.

Present the plan annually rather than requesting devices reactively. A rolling replacement plan gets funded; individual requests get deferred.

Redeployment

The option between replace and keep.

A device unsuitable for one role may suit another. A developer's machine at three years is frequently better than what a light user has.

Cascade deliberately, with the register updated and the device wiped and re-imaged properly.

Cap the total age regardless of cascade, since a six-year-old device is a security and support problem whoever is using it.

Record the cascade, or the register loses track of age and the whole assessment breaks down.

The assessment at the target date

Six questions that replace an automatic replacement with a decision, and take five minutes per device.

Is it still under vendor support for firmware and operating system updates.

Is it under warranty, or what would an out-of-warranty repair cost.

How many support tickets has it generated in the last year.

Does it still run the current standard build at acceptable speed.

Does it meet the holder's actual requirements, which may have changed with their role.

What is its residual value now against a year from now.

Two or more negative answers: replace. One: extend by a year and reassess. None: extend and diary it.

Smoothing the replacement peak

A fleet bought in one batch reaches refresh in one batch, and the budget request is unwelcome.

Model the fleet by purchase year, which takes minutes from the register.

Identify the peaks three or four years ahead.

Smooth deliberately: replace some early, extend some late, spreading the cohort over two or three years.

Prioritise by role and condition rather than by date within the cohort.

Present the smoothed plan annually, as a rolling figure rather than a spike.

A steady annual number gets approved. A number that triples every third year gets deferred, which produces an ageing fleet and a larger problem the following year.