Managed IT
Hardware rarely fails politely. It fails on a Friday afternoon, on the machine belonging to whoever is closing the quarter, and the replacement gets bought at list price with overnight shipping because nobody planned for it. A refresh cycle is not really about the equipment. It is about moving that purchase from an emergency into a budget line you set twelve months earlier.
Most organizations do not decide to run hardware until it dies. They decide not to decide, one quarter at a time, and the machine keeps working right up until the morning it does not. The equipment was never the problem. The problem was that replacing it had no date attached, so it lost every argument against things that did.
What running equipment to failure costs
The Uptime Institute attributes 73% of unplanned IT outages to aging or failed hardware, and the important word in that sentence is unplanned. These are largely predictable failures happening on an unpredictable schedule, which is the worst combination available.
The costs stack in a specific order, and only the first one appears on an invoice.
You pay retail, urgently
Planned procurement gets partner pricing, sensible lead times and the configuration you actually wanted. Emergency procurement gets whatever is in stock, at whatever it costs, shipped at whatever it takes. The gap between those two prices is pure avoidable spend, and it repeats every time.
Somebody is not working
A failed laptop is one person idle for as long as it takes to source, image and hand over a replacement. A failed server is a department. The productivity loss usually dwarfs the hardware cost, and it never gets attributed to the refresh decision that was deferred two years earlier.
The slow version, which is worse
Outright failure is the visible case. The more expensive one is equipment that still works but has become slow: machines that take four minutes to boot, that cannot run the current OS build, that everyone quietly works around. Nobody logs a ticket for a computer that is merely tedious. The cost lands as lost time spread thin across a lot of people, where it is invisible and enormous.
Useful life by device type
Planning Ranges
The ranges below are the ones most IT teams plan against. Treat them as rules of thumb rather than standards, because the number that should actually drive your decision is specific to each device and it is already knowable: when the warranty ends, when the manufacturer stops supporting it, and when it can no longer run a supported operating system. Age is a proxy. Those dates are facts.
What should actually trigger replacement
Laptops and desktops
Warranty expiry · OS support lifecycle · Battery health · Repeat support tickets
Laptops age faster than desktops because they get carried, dropped and cycled through batteries, so many teams plan them a year shorter. The better trigger than age is the OS support lifecycle: a machine that cannot run a supported build of the operating system has become a security problem regardless of how it performs. Watch repeat support tickets per device as well. When the same machine generates its third or fourth ticket, the labour spent has usually overtaken the residual value.
What should actually trigger replacement
Servers and storage
Warranty and support contract · Vendor end-of-life · Capacity headroom · Parts availability
Server refresh usually gets anchored to the warranty and support contract, which is sensible, because running production on hardware you cannot get same-day parts or vendor support for is the actual risk rather than the age itself. Storage carries a second trigger: watch capacity headroom and plan the replacement while you still have room to migrate onto it. A storage array that fills up before its replacement arrives turns a planned project into an emergency one.
What should actually trigger replacement
Network equipment
Firmware end-of-support · Throughput vs current circuit · Feature gaps · Vendor EOL notices
Switches, firewalls and access points tend to keep working long past the point where they should be replaced, which is exactly the trap. The trigger here is rarely performance. It is the day the vendor stops shipping firmware updates, at which point a device sitting on your perimeter stops receiving security fixes and quietly becomes the weakest thing on the network. Vendor end-of-life notices are published well in advance, so this is one of the few refresh dates you can genuinely put in a calendar years ahead.
Age is the weakest signal you have
Every range above is a starting point for budgeting, not a replacement rule. A three-year-old laptop used for email has plenty of life left. A three-year-old laptop running design software has probably been the bottleneck for a year. Two things sharpen the decision: tracking warranty and end-of-support dates per device so replacement has a real deadline attached, and watching support tickets per device so the machines actually costing you time surface on their own.
Building the refresh cycle
Five steps, and the first one is the only one most organizations are actually missing.
Start with an inventory that has dates in it
Not a list of devices. A list of devices with purchase date, warranty expiry, and manufacturer end-of-support against each one. Without those columns you cannot forecast anything, and the refresh conversation stays a matter of opinion about which machines feel slow.
Stagger replacements, do not batch them
Replacing everything in one year creates a capital spike and guarantees you repeat it on the same cycle forever. Splitting the fleet so a predictable share refreshes annually smooths the budget and means you are never carrying an entire estate that aged out simultaneously.
Put it in the forecast before it is urgent
Once devices carry warranty and end-of-support dates, next year's replacement spend is arithmetic rather than a guess. That is the number that lets Finance plan, and it is the argument that wins the budget conversation, because you are presenting a schedule rather than requesting an exception.
Standardize the models you buy
Fewer configurations means fewer images to maintain, fewer spare parts to hold, faster deployment and simpler support. Every one-off purchase made to solve a specific problem becomes a long-term support obligation that outlives whoever requested it.
Plan the exit, not just the purchase
Decommissioning is where refresh plans quietly fail. Devices leaving the fleet still hold data, still hold credentials, and still appear in your asset count until somebody removes them. Secure disposal and asset record removal belong in the plan alongside the order, or the old equipment accumulates in a cupboard as an unmanaged risk.
Refresh Readiness Checklist
The Checklist
Fifteen questions to test whether you have a refresh plan or a habit of replacing things when they break. Tick the ones you can answer without going and asking someone.
Tick what you can answer without checking. The blanks are the gaps.
Inventory & Dates
Does your asset list carry purchase dates?
A list of devices without dates cannot forecast anything. It is a count, not a plan.
Do you know which devices are out of warranty right now?
This is the line between a repair and a replacement, and most teams find out at the point of failure.
Do you track manufacturer end-of-support dates?
Published years in advance, so this is one of the few refresh deadlines you can genuinely calendar.
Is the inventory automated, or maintained by hand?
Manual asset lists only ever drift one way, and the devices missing from them are the oldest ones.
Age & Risk
How many machines cannot run a currently supported OS build?
Those have stopped being a performance question and become a security one.
Do you track support tickets per device?
The machines generating repeat tickets are telling you the labor cost has overtaken the residual value.
Do you know which single failure would hurt most?
Usually one aging server or one network device. Knowing which is the cheapest risk assessment available.
Is any network hardware past vendor firmware support?
A perimeter device no longer receiving security fixes is the weakest thing on the network, and it still works fine.
Budget & Planning
Is next year's replacement spend in the forecast?
If it is not, every replacement will arrive as an exception request competing against planned work.
Are replacements staggered, or will a large batch age out together?
Fleets bought all at once come due all at once, and the spike repeats on the same cycle indefinitely.
How many different models are you supporting?
Every one-off purchase becomes a long-term support obligation that outlives whoever asked for it.
What did you spend on emergency replacements last year?
The gap between that and planned procurement pricing is the cost of not having a cycle.
Disposal & Handover
Is there a documented process for wiping retired devices?
Equipment leaving the fleet still holds data and credentials until somebody deliberately removes them.
Are retired devices removed from the asset record?
Otherwise your device count, and every percentage calculated from it, is quietly wrong.
How long does it take to get a replacement into someone's hands?
Sourcing plus imaging plus handover. That number is how long a person waits, and it is usually longer than anyone assumes.
Frequently asked questions
Most IT teams plan laptops and desktops on a three to five year cycle, with laptops often replaced a year earlier because they take more physical wear. Treat that as a budgeting rule of thumb rather than a rule. The stronger triggers are specific to each machine: whether it is still under warranty, whether it can still run a supported operating system build, and how many support tickets it has generated. A device that cannot run a supported OS has become a security problem regardless of how well it performs.
A hardware refresh cycle is a planned schedule for replacing equipment before it fails, rather than reacting when it does. In practice it means holding an asset inventory with purchase dates, warranty expiry and manufacturer end-of-support against every device, staggering replacements so a predictable share of the fleet refreshes each year, and carrying that spend in the budget forecast. The point is to move replacement from an unplanned invoice to a scheduled line item.
The Uptime Institute attributes 73 percent of unplanned IT outages to aging or failed hardware, and the significant word is unplanned. These failures are largely predictable in aggregate but unpredictable in timing, so equipment kept past its useful life fails on its own schedule rather than yours. The more expensive pattern is slower: machines that still work but have become tedious generate no tickets while quietly costing time across a lot of people.
Server refresh is commonly planned around five years, but the more useful anchor is the warranty and support contract rather than the age. Running production workloads on hardware where you cannot obtain same-day parts or vendor support is the actual risk. Storage carries a second trigger worth watching: plan the replacement while you still have capacity headroom to migrate onto it, because an array that fills before its replacement arrives turns a planned project into an emergency.
Usually when the vendor stops shipping firmware updates rather than when performance degrades. Switches, firewalls and access points tend to keep working well past the point they should be replaced, which is the trap. A perimeter device no longer receiving security fixes becomes the weakest thing on your network while appearing to function normally. Vendor end-of-life notices are published well in advance, making this one of the few refresh dates you can calendar years ahead.
Start by adding warranty expiry and manufacturer end-of-support dates to your asset inventory, because once those exist next year's replacement spend becomes arithmetic rather than a guess. Then stagger the fleet so a predictable share refreshes annually instead of a single capital spike that repeats forever. Presenting Finance with a schedule rather than an exception request is what usually wins the conversation, and it also surfaces what emergency replacements cost you last year.
It needs secure data destruction and removal from the asset record, and both belong in the refresh plan alongside the purchase. Devices leaving the fleet still hold data and credentials until somebody deliberately removes them, and they continue to appear in your device count until the record is updated, which quietly distorts every percentage calculated from it. Decommissioning is where refresh plans most often fail, because the work has no deadline attached once the replacement is deployed.
The comparison people run is repair cost against replacement cost, which leaves out the two figures that matter more. The first is the productivity loss while someone waits, which usually exceeds the hardware cost outright. The second is the support labor already spent on that device, which is why tracking tickets per machine is useful. Once a device has generated its third or fourth ticket, the accumulated labor has generally overtaken whatever residual value it still had.
Want a refresh plan with dates in it?
Get a free technology assessment. We'll inventory what you have, flag what's aging out, and give you a forecast you can budget against.
