Hardware Refresh Cycle: Picking the Year You Replace Machines

TL;DR

• A hardware refresh cycle is the age at which you replace a working machine, and three years is a convention rather than a finding.
• If your fleet is small and nobody complains about their laptop, you do not need a cycle. You need a rule for when somebody does.
• The right number comes from your own support data, not from a vendor's depreciation schedule or a competitor's policy.
• Age is a poor predictor on its own. Condition signals beat it, and a combination of the two beats either.
• The cost of replacing too early is visible and the cost of replacing too late is not, which is why most fleets run older than their stated policy.
• Replacing in a distributed company costs more than the hardware, because every refresh is also a delivery and a recovery.

The Policy That Said Three Years and the Fleet That Averaged Four

A 400-person company had a written three-year refresh policy, approved, budgeted and referenced in the IT plan. Somebody pulled the actual age distribution for a board paper.

The mean was 4.1 years. Worse than the mean, the distribution had a long tail: 61 machines over five years old, and nine over six. The newest third of the fleet had been bought in the last eighteen months, mostly for new starters, which pulled the average down and concealed how old the oldest were.

Nobody had decided to run the fleet to four years. What had happened was that each year's refresh budget covered roughly the number of machines that had become unbearable, and the machines that were merely old waited. The policy described an intention and the budget described the reality, and because the policy existed nobody checked which one the fleet was following. The nine six-year-old machines belonged to people who had never complained, which is the group a complaint-driven process structurally cannot reach.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

So the useful question is not what the cycle should be. It is what it actually is, and whether the gap between the two is a decision or an accident.

When You Don't Actually Need a Cycle

When the manual way is genuinely fine

Under about forty machines, where somebody knows every device and replaces one when it stops being good enough. This is responsive, cheap and perfectly defensible, and it works because the person deciding can see the whole fleet. A formal cycle at this scale adds a budgeting process and removes judgement.

When friction starts appearing

The first signal is usually a manager escalating on behalf of their team rather than an individual complaining. That means the problem has become visible enough to be a team issue, and it also means the people most affected have already decided that asking is not worth it.

When it becomes a liability

When machine age starts producing security exposure rather than inconvenience: devices that cannot run a current operating system, or that have dropped out of vendor support entirely. This is a different argument from productivity and it is the one that usually releases budget.

The edge case that forces it

A platform change. An operating system version that will not run on older hardware, or a core tool whose requirements move, converts a gradual problem into a deadline with a known date. These are the best possible moments to fix a refresh cycle because the business case writes itself.

Five Questions People Ask First

"Why does everybody say three years?" Mostly because it matches common depreciation schedules and warranty terms rather than because anybody established that machines stop being useful at 36 months. It is a reasonable starting assumption and a poor conclusion, and the gap between those two is where money is either wasted or saved.

"Is it cheaper to keep machines longer?" In hardware terms obviously yes, and that is the smaller half of the calculation. The costs that rise with age are support time, failure-driven downtime, and the productivity difference on machines that have become slow. Those are real and they are diffuse, which is why they lose arguments against a capital figure that sits in one line.

"Should everybody be on the same cycle?" No, and insisting on it is a common and expensive mistake. Roles differ enormously in what they ask of a machine, and a uniform policy either over-provisions the majority or under-provisions the minority who need the capability. Differentiating by role is more defensible than it sounds, provided you write down the basis.

"What about devices that fail early?" Failure replacement is a separate process from scheduled refresh and should be budgeted separately. Mixing them means a bad year for failures eats the planned refresh, which is exactly how a three-year policy becomes a four-year fleet.

"Do we have to replace, or can we upgrade?" Increasingly not, since memory and storage are soldered on most current business laptops, so the upgrade path that used to extend life has largely closed. Battery replacement is the exception and it is frequently worth doing, because a degraded battery is one of the most common reasons a machine feels finished when it is not.

Working Out Your Own Number

Four inputs, all of which you already have, and none of which requires a vendor.

Hardware tickets by device age. Group your hardware-related tickets by the age of the machine at the time of the ticket. Almost every fleet shows a clear inflection: a flat period, then a rise. That inflection is your real cycle, and it is specific to your hardware, your workload and your environment.

Two cautions on this one, because it is the input most likely to mislead. Filter out tickets that are about software or access and happened to be raised from an old machine, since those will drown the signal. And remember that people on very old machines often stop raising tickets at all, having concluded nothing will be done, so a flat or falling rate in your oldest cohort is more likely to be resignation than reliability. Where the oldest group looks suspiciously quiet, go and ask three of them rather than treating the number as good news.

Failure rate by age cohort. The proportion of machines of each vintage that have had at least one hardware failure. More stable than ticket counts and easier to explain to finance. It is also the figure that survives a change of ticketing system, which matters if you want a trend longer than your current tooling has existed, since purchase dates and failure records usually outlive the helpdesk they were recorded in.

Battery health by age. The single most predictive component and the easiest to measure, since management tooling reports cycle counts and health percentages. Batteries frequently degrade before anything else does, and they are the reason a three-year-old machine feels worse than it performs. Pull this one first if you only have time for one input, because it is already collected, it needs no interpretation, and it correlates well with how people describe their machines.

Residual value by age. What you can sell or trade a machine for at each age. This declines faster than most people assume and it is the input that argues for replacing earlier, because the value you recover at three years is meaningfully higher than at four and a half.

Getting that last figure is easier than it sounds and is worth doing from a real quote rather than an assumption. Send a buyback vendor the specification and age of a representative sample and ask what they would pay today, then ask what they would pay for the same machines in eighteen months. Two numbers from one email, and together they turn the replace-earlier argument from an assertion into arithmetic a finance partner can check. Do it before you write the business case rather than after, since the shape of the decline frequently moves the recommended cycle by half a year in one direction or the other.

Plot the first three against the fourth and the crossover is your answer. For most office fleets it lands somewhere between three and four years and, critically, it is not the same number for every role.

The Four Replacement Triggers

The combination that works for most companies is age as a floor, condition as an override and event as an interrupt. Age gives finance a predictable baseline, condition catches the machines that need replacing sooner, and an event trigger handles the occasions when the decision is taken out of your hands.

Role belongs in the standard rather than in the cycle: define what each role is issued, and let the same cycle apply to everybody.

What a Refresh Actually Costs in a Distributed Company

The hardware is the part everybody budgets. The rest is the part that makes a refresh get deferred.

A delivery per device. Each replacement is an international shipment to a home address, with the same customs and failed-delivery risks as an onboarding. For a fleet spread across several countries this is the largest non-hardware line.

A recovery per device. The old machine has to come back, and it comes back from somebody who now has a new one and therefore no incentive to act. Refresh recovery rates are generally worse than leaver recovery rates for precisely this reason, which surprises people.

An overlap period. The employee has both machines for some days. That is unavoidable and it is also where old devices go missing, because the one they are no longer using stops being their concern.

Data migration, usually by the employee. Modern setups make this lighter than it was, and it is still a few hours of somebody's time multiplied by the fleet.

Disposal or resale of the old fleet, which is its own exercise and belongs in the refresh budget rather than being discovered afterwards.

A refresh programme costed on hardware alone will be under-budgeted by a meaningful margin for a distributed company, and the gap shows up as a project that stalls halfway.

Reading the Age Distribution Properly

The opening example turned on a mean concealing a tail, and that is the normal case rather than an unlucky one. Four ways to look at the same data, in increasing order of usefulness.

The mean age. Almost useless on its own, and the number most likely to appear in a board paper. It moves downwards every time you hire, which means a growing company's fleet appears to get younger while its oldest machines get older.

The median. Better, and still silent about the tail. A median of 2.8 years is consistent with a hundred machines over five.

The oldest decile. The first genuinely useful cut. The age of the oldest ten per cent, and the count of machines above your policy threshold. This is the number that describes your actual exposure and it is the one to put in front of a budget holder.

The distribution by cohort, with names attached. The most useful and the most uncomfortable. A list of every machine over the threshold with its holder, their team and their location. This converts an abstraction into a set of people, which is both how you plan the logistics and how the unfairness becomes visible.

Produce the last one quarterly rather than annually. A refresh programme planned once a year against a snapshot from January is planning against a fleet that no longer exists by the time the machines arrive.

One pattern worth looking for specifically: machines held by people who joined before a particular system change. Fleets often contain a cohort bought under an old standard, and that cohort ages together and will need replacing together, which is a budgeting fact worth knowing a year ahead rather than discovering.

How to Choose: Five Questions Before You Talk to Any Vendor

What is your fleet's actual age distribution? Not the average, the distribution, with the oldest decile called out. The average is the number that conceals the problem.

Where does your ticket rate inflect by age? This is your real cycle and it takes an afternoon to produce from data you already hold.

What is your recovery rate on refresh specifically? If it is poor, a refresh programme quietly becomes a programme for losing old machines, and the residual value in your business case will not materialise.

Can you replace in cohorts rather than continuously? Cohorts are cheaper per device because shipping and recovery can be batched, and they are more disruptive in a concentrated way. Most distributed companies should do cohorts by region rather than continuous replacement.

Who approves an off-cycle replacement, and on what basis? Without a named approver and a stated basis, the answer defaults to whoever asks most persistently, which is the pattern the opening example produced.

The Options

Figures below were read from each vendor's own pricing page, most recently 9 October 2026.

Doing it yourself with a tracked age field

Best for: any company with a reliable register and somebody to run the programme.

Why it works: the whole decision is arithmetic on data you already hold, and the tooling requirement is an age field and a report. Most companies do not need a product for this; they need somebody to own it.

Where it struggles: it depends entirely on register accuracy. A refresh planned from a register that is 70 per cent accurate will order the wrong number of machines.

Snipe-IT

Best for: teams who need the register that makes refresh planning possible and have no budget.

Why companies choose it: the self-hosted edition is free and open source, and it holds purchase dates, warranty expiry and custom fields, which is everything a refresh plan needs. Hosted tiers are published at $39.99 monthly or $399.99 annually for Basic, $99.99 or $999.99 for Small Business, and $249.99 or $2,499.99 for the smaller dedicated plan.

Where it struggles: self-hosting is a real commitment, and it tells you what to replace without helping you ship or recover anything.

AssetTiger

Best for: small teams wanting a hosted register priced by asset count.

Why companies choose it: published pricing at $20 a month for 500 assets, $40 for 2,500 and $75 for 10,000, reducing to $18, $37 and $69 on annual billing, with unlimited users throughout.

Where it struggles: the widely cited 250-asset tier is a 30-day trial on its own pricing page rather than a permanent free plan. Register only, with no logistics.

Lifecycle platforms

Workwize, Deel IT, Firstbase, GroWrk and allwhere will execute the physical half of a refresh across markets, which is the expensive half for a distributed fleet. None publishes a price. Shortlist on country coverage against your actual markets.

RemoAsset

Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It appears here because it competes in this category and is assessed against the same criteria as everything else on this page, with its limitations stated in the same detail.

Best for: refreshes where the recovery of the old machine matters as much as the delivery of the new one, which is most of them.

Why companies choose it: the delivery and the return are handled in one arrangement, so the overlap period has an owner and the old device has a scheduled collection rather than a hope. Devices can be reissued in region, which is where refresh residual value actually gets captured.

Where it struggles: it publishes no price and requires a demo. It is weaker for hardware it did not originally supply, since it inherits whatever register you have. And it is not a certified disposal vendor, so the end of the old fleet is a separate purchase.

The Comparison

The Decision Table

The Condition Signals Worth Watching

Age as a floor is easy. Condition as an override needs somebody to decide which signals matter, and most management consoles report more than anybody looks at. Five that earn attention, in rough order of predictive value.

Battery health and cycle count. The strongest single predictor and the most widely reported. A battery below about 80 per cent of design capacity changes how a machine feels in daily use far more than its processor does, and it is the reason perfectly capable machines get described as slow.

Repeat hardware tickets from the same device. Two or more in six months is a signal regardless of what each one was. Machines that develop problems tend to keep developing them, and the pattern matters more than any individual fault.

Failed or stalled operating system updates. Frequently the first indication that a machine is drifting out of support, and it is a security signal as well as a performance one, which makes it the easiest to get budget against.

Storage pressure. A drive consistently near capacity degrades performance and generates support contacts that look like user error. Cheap to detect and sometimes fixable without replacement. Treat it as a prompt to investigate rather than as a replacement trigger on its own, since a full drive is frequently a housekeeping problem rather than a hardware one and replacing the machine simply moves the files.

Thermal events and fan behaviour. Less commonly reported and genuinely useful where available, since sustained thermal throttling is a good predictor of both poor experience and imminent failure.

What to do with them is the part that is usually missing. Pick two, set a threshold for each, and generate a list monthly of machines that cross either one. Send that list to whoever approves replacements. A signal nobody reviews is indistinguishable from a signal nobody collects, and most companies have the data and no routine.

Running the Programme

Six practical points that decide whether a refresh lands.

Replace in cohorts by region, not continuously and not globally. Regional batching lets you ship and collect together, and it keeps the old devices in the market where they can be reissued.

Book the collection when you book the delivery. The single highest-return habit in a refresh. A collection arranged after delivery competes with the employee's new laptop for their attention and loses.

Set an overlap limit and enforce it. Five working days is generous. Beyond that the old machine stops being on anybody's mind.

Communicate what is happening and why. People on four-year-old machines who have not complained often assume the new machine is coming out of their team's budget, or that they are being singled out. A one-line explanation prevents a surprising amount of friction.

Decide the old fleet's destination before the first delivery. Reissue, resale or disposal, settled in advance, because the decision made device by device after the fact is the one that fills a cupboard.

In practice the outgoing fleet usually splits three ways rather than going to a single destination, and deciding the split in advance is what makes it manageable. The best machines become your regional spare stock, which is the cheapest possible answer to the next hire in that market and removes a future international shipment. The middle group goes to resale while it still has value, which is the group most damaged by delay. The genuinely finished machines go to certified disposal. Agreeing the rough proportions before the programme starts means each returning device has an obvious destination on arrival rather than a decision attached to it, and decisions attached to individual devices are exactly what does not happen during a busy refresh.

And track completion by cohort rather than by device. A refresh that is 94 per cent complete with 23 machines outstanding is not nearly finished; it is in the phase that will take as long as the rest put together.

The long tail deserves planning rather than persistence. The last ten per cent is made up of people on extended leave, people in markets with awkward logistics, people who have deferred twice, and a few machines nobody can locate. Each needs a different answer, so handle them as a named list with an owner and a deadline rather than as a continuation of the main programme. Set a date at which the remainder is closed out, decide in advance what happens to a machine still outstanding at that point, and record those as exceptions rather than leaving the programme formally open for a year. A refresh that never officially ends is a refresh whose next cycle starts late.

Funding It Without a Capital Spike

A refresh cycle creates a lumpy budget, and the lumpiness is a real obstacle rather than a presentational one. Four ways companies smooth it, with what each actually costs.

Rolling replacement, a portion every quarter. Replace a quarter of the eligible machines each quarter rather than the whole cohort annually. Smoothest for budgeting, and it loses the batching efficiency that makes distributed refresh affordable, so it suits single-location fleets better than distributed ones.

Regional cohorts on a rotating schedule. Each region refreshed on its own annual cycle, staggered across the year. Keeps the shipping and collection batching while spreading the spend, and it is the arrangement that works best for most distributed companies.

Leasing or device as a service. Converts the spike into a running cost entirely, at the price of a finance charge and an end-of-term exercise. A legitimate answer to a cash-flow problem and not a cheaper answer in total.

Funding from resale. Selling the outgoing fleet to part-fund the incoming one. Genuinely useful and dependent on two things most companies are weak at: recovering the old machines, and recovering them early enough that they still have value.

The fourth is the one worth pushing on, because it connects the refresh to recovery in a way that makes both easier to justify. A refresh business case that includes a credible resale line is a smaller ask, and the only way to make that line credible is to improve the recovery rate first. That is a useful sequencing argument: fix recovery, then refresh, rather than discovering during the refresh that the residual value you promised will not arrive.

One caution on resale assumptions. The value in your business case should be based on machines at the age you will actually sell them, not at the age your policy says, and those differ by the same gap as the opening example. A quote obtained for three-year-old machines does not apply to a fleet that turns out to be four and a half.

What Getting This Wrong Costs

Replacing too early costs capital, and it is the visible failure. It is also the less common one, because the pressure in most organisations runs the other way.

Replacing too late costs in three places that do not appear as hardware spend. Support time on machines that generate repeat tickets. Lost working days when an old machine finally fails and the replacement has to be shipped internationally. And residual value, which falls steeply, so a fleet replaced at four and a half years rather than three recovers materially less when sold.

The third cost is the distributional one from the opening example. A complaint-driven process systematically gives the newest machines to the most vocal and leaves the oldest with the people least likely to ask, which is an unfairness nobody chose and which correlates uncomfortably with seniority and confidence. An age-based backstop exists mainly to fix this.

There is a fourth cost that falls on hiring and retention and never gets attributed to the refresh cycle. A candidate joining from a company that replaces machines on a predictable rhythm notices immediately when they are handed something four years old, and so does an existing employee who watches a new starter receive a better machine than theirs. Neither of them raises it as a hardware issue. It surfaces as a general sense that the company does not invest in the people already there, which is both unfair as a reading and entirely understandable given the evidence in front of them. An age floor that fires without anybody asking is the cheapest available fix for this, and it costs nothing beyond deciding to run it.

So the question worth asking before the next budget round is not whether three years is right. It is what your fleet's oldest decile looks like, and who those machines belong to.

What to Tell People, and When

A refresh is one of the few IT programmes that touches everybody, and the communication around it is usually an afterthought that creates most of the friction.

Tell the whole population the rule, not just the people being replaced. If the policy is an age floor with a condition override, say so to everybody. The absence of a stated rule is what makes an individual replacement look like a favour, and it is why people who need a machine ask repeatedly while people who need one more do not ask at all.

Give individuals two weeks of notice, not two days. They need to think about what is on the machine, when they can be at home for a delivery, and whether the timing collides with anything. A refresh that arrives unannounced during somebody's busiest fortnight gets deferred by them, and a deferred refresh becomes an outstanding one.

Be explicit that the old machine is coming back and when. This is the single sentence that most improves refresh recovery rates. The default assumption, held sincerely by a lot of people, is that an old laptop being replaced is effectively theirs now.

Say what happens to their data and what they need to do. Even where migration is largely automatic, people worry about it, and the worry is what causes somebody to delay accepting a new machine for three weeks.

And publish the age distribution internally, at least to managers. It converts the programme from something IT is doing to something the company can see the shape of, and it makes the case for next year's budget without anybody having to argue it.

When You're Ready to Move Beyond Replacing on Complaint

Replacing machines when somebody says theirs is bad is responsive, cheap and it does work for a while. It also has one structural flaw that cannot be fixed by doing it better: it only ever reaches the people who ask.

That flaw stays invisible while the fleet is small and everybody is in one place, because you can see the old machines. It becomes a real problem at the point where the person deciding cannot observe the fleet directly, which for most companies is the second office or the first few remote hires.

The sequence that works is short and mostly analysis. Pull the age distribution, including the oldest decile by name. Plot hardware tickets against device age and find your inflection point. Check battery health across the fleet, since it is the most predictive single signal and usually already reported. Then set an age floor as a backstop, a condition override for machines that need replacing sooner, and a named approver for exceptions. Budget delivery, recovery and overlap alongside the hardware, because in a distributed company those are what make a refresh stall. None of that requires buying anything, and it converts a cycle that exists on paper into one the fleet actually follows.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why the lifecycle platforms above are listed with no price rather than an estimate.