Asset lifecycle

Hardware refresh cycles: how often to replace laptops, desktops and servers

Every IT budget conversation eventually arrives at the same question: how long should this hardware last? A sensible hardware refresh cycle is the difference between replacing machines on your terms and replacing them in a panic when they fail. This guide covers realistic lifespans by device class, the signals that matter more than age, and how to budget a rolling refresh, whether you look after one company's estate or a dozen clients' worth.

What a hardware refresh cycle actually is

A hardware refresh cycle is a standing policy that says how long each class of device stays in service before it is replaced, and a plan that spreads those replacements across budget years. That is all. It is not an enterprise asset management programme, and you do not need one to have a refresh cycle. You need an accurate inventory, an agreed lifespan per device class, and a spreadsheet or a platform that can tell you what falls due next year.

The alternative, running everything until it dies, feels thrifty and is usually the most expensive option available. An aged machine does not fail politely at a convenient moment. It fails on a Tuesday morning with a deadline attached, and the true cost includes the emergency purchase at whatever price is available that week, the hours rebuilding a user's environment from nothing, and the productivity lost while all of that happens. Planned replacement moves the same spend to a moment you chose, at a price you negotiated, with the user's data migrated calmly in advance.

How often should you replace laptops, desktops and servers?

There is no single number, but there are defensible ranges that most of the industry has converged on:

• Laptops: 3 to 4 years. They travel, they get dropped, batteries degrade and hinges wear. By year four, repair cost and lost productivity usually overtake replacement cost. Machines doing heavy work, development, CAD, video, sit at the short end.
• Desktops: 4 to 5 years. No battery, no travel, easier to upgrade. A desktop that was decently specified at purchase can do five years without the user suffering for it.
• Servers: 5 to 7 years. The practical limit is usually vendor support and parts availability rather than the hardware itself. Running production workloads on a server the vendor no longer supports is a risk decision, not a savings decision.
• Network kit and firewalls: 5 to 8 years. Switches are long-lived, but firewalls are only as good as their security updates. The day a firewall leaves vendor support is the day it becomes a liability, whatever its uptime says.

Align the lifespan with the warranty where you can. Buying laptops with a three-year warranty and running them for four means the final year is uninsured, which is exactly when failures cluster. Either buy the extended warranty or shorten the cycle to match.

The Windows 11 long tail is forcing the issue

Plenty of estates are having this conversation now whether they planned to or not. Windows 10 left support in October 2025, and Windows 11's hardware requirements, TPM 2.0 and a roughly 2018-or-newer processor, mean a real share of older machines cannot simply be upgraded in place. Those devices are not just old, they are stuck: still working, still logged in, and no longer receiving free security updates.

The useful lesson generalises beyond this one migration: operating system support windows are part of hardware lifespan. A machine that cannot run the next supported OS is end-of-life on a schedule someone else set, and your refresh cycle should see that coming years out, because the ship dates are published years in advance.

Age is a proxy: the signals that matter more

Calendar age is the planning number, but it is a proxy for the things you actually care about. A four-year policy applied blindly replaces some machines that are fine and misses some that are quietly ruining someone's working day. The better refresh decisions weigh signals like these:

• Disk health. SMART warnings and reallocated sectors are the closest thing hardware gives you to advance notice. A machine with a degrading disk goes to the top of the list regardless of age.
• Battery wear. A laptop that no longer survives a meeting without a charger has effectively become a desktop, and its user knows it.
• Ticket history. Three tickets in six months from the same device is a pattern. The support time already spent on it is usually a meaningful fraction of the replacement cost.
• Performance drag. Boot times, memory pressure and CPU saturation during ordinary work. Users rarely report slowness, they just absorb it, so measure it rather than waiting to be told.
• Support status. Warranty expiry, OS eligibility and vendor end-of-support dates, as above.

The practical approach is a policy with an override in each direction: devices are scheduled by age, promoted early when the signals are bad, and occasionally kept a little longer when a healthy machine is doing light duty for an undemanding user.

Rolling refresh beats big bang: the budget maths

The other half of a refresh cycle is how the spend lands, and the answer is almost always: spread it. Take an estate of 100 laptops on a four-year cycle. Replacing them as one project means a large procurement roughly every four years, a bruising budget line, a deployment crunch, and then four quiet years in which the entire fleet ages in lockstep towards the next cliff.

The rolling alternative replaces a quarter of the fleet every year: 25 machines, every year, forever. The total spend over four years is identical, but everything else improves. The budget line is flat and predictable, which finance departments and clients both prefer. Deployment becomes routine rather than a project. The fleet always contains a spread of ages, so no single OS deadline or bad batch can strand half your machines at once. And each year's purchase benefits from that year's price and performance rather than locking the whole estate to one moment in time.

The same logic scales down. An estate of 20 laptops on a four-year cycle is five machines a year, which is a purchase order, not a project. If you are starting from an estate that has never had a refresh plan, begin with the oldest quartile this year and the cycle establishes itself automatically.

Building a refresh plan you can defend

A workable plan takes an afternoon if the inventory exists, and it looks like this:

1. Get the inventory straight. Every device, with model, purchase or first-seen date, warranty status, OS eligibility and assigned user. If devices are appearing that nobody procured, fix discovery first: a refresh plan built on a partial inventory is fiction. This is the same discovery discipline that anchors a good client onboarding, and it pays off here for years.
2. Assign a lifespan per class, using the ranges above adjusted for how hard your machines actually work.
3. Generate the due list. Sort by age against lifespan and you have next year's replacement list and a defensible number to put in the budget. Multiply out the following two years while you are there: a three-year forward view is what turns hardware from a surprise into a line item.
4. Apply the overrides. Promote the machines with bad signals, demote the healthy outliers, and note why, so the plan survives scrutiny.
5. Review annually. Lifespans drift, requirements change, and last year's exceptions should not silently become policy.

If you run an MSP, this plan is also one of the easiest pieces of proactive value you can show. A three-year hardware forecast per client, presented once a year with prices attached, answers the "what are we paying you for" question better than any ticket count, and it turns emergency hardware purchases, the thing clients remember and resent, into planned ones.

Retirement is part of the cycle

A refresh plan that stops at "new laptop delivered" is only half finished. The outgoing device still holds company data and still shows up in licence counts, and old machines have a way of living in cupboards as unmanaged, unpatched spares that resurface on the network a year later. Close the loop deliberately: wipe the disk to a documented standard or destroy it, keep a record of the disposal for compliance, recycle through a certified e-waste route, and mark the asset retired in the inventory the same day. A short written checklist here is worth more than good intentions, because disposal is the step nobody is ever chased for.

Where this fits with Helios

Almost everything above depends on data you should not have to collect by hand. Helios already maintains the live inventory its agent sees, hardware model, age, disk health, OS version and warranty-relevant details, alongside each device's ticket history, so the asset lifecycle view can surface what is due, what is degrading early and what is quietly costing you support time. That evidence is what turns a hardware refresh cycle from a guess into a schedule, and because the same data sits behind patching and monitoring, the machine you are about to replace and the machine you are about to patch are finally the same record.