Every piece of technology in your business is on a countdown — and unlike most business risks, this one publishes its schedule. Workstations, servers, firewalls, and switches age at knowable rates toward two overlapping cliffs: rising failure probability, and the end of vendor support. Lifecycle planning is the discipline of reading that schedule and replacing things on purpose — and its absence has a name too: run-to-failure, which is just replacement planning delegated to the hardware, at emergency prices, on a date of its choosing.

The realistic lifespans

The working numbers, honed by decades of fleets: workstations and laptops, 4–5 years — past that, failure rates climb, batteries and drives tire, and the quiet cost arrives first: the machine that makes everything feel slow taxes its user daily long before it dies · servers, 5–7 years, with the warranty question deciding the far edge — a critical server past vendor support is a risk finding, not a bargain · firewalls and network gear, 5–7 years, with a sharper cliff than people expect: a firewall past its software support date stops receiving security patches, which converts your front-door lock into your front-door vulnerability · phones and tablets, 3–4 years, driven by OS support windows more than hardware. These aren’t rules — a lightly-used front-desk machine can stretch, a CAD workstation earns a faster cycle — but stretching should be a decision with a reason, not a default with a fuse.

Why run-to-failure loses the math it thinks it’s winning

Squeezing “free” extra years feels frugal; the accounting disagrees. The machine that dies in service costs its replacement plus the downtime at your hourly number, plus emergency logistics (expedited shipping, whatever’s in stock rather than the standard model, a technician’s urgent afternoon), plus the data question if the backup story on that box was thin. Meanwhile the pre-failure years weren’t free either: aging fleets generate a rising drizzle of tickets and slowness that reactive environments pay in workarounds. Planned replacement pays the same hardware bill on a calm day, minus every other line. The exception that proves it: genuinely low-stakes machines can rationally run longer — the point is choosing which ones, out loud, with the risk owned.

The math: a rolling budget, not a cliff

The mechanism is arithmetic on the inventory: every device with its age, sorted. Then: (count ÷ lifespan) × unit cost = the annual refresh number — twenty workstations on five years means four per year, every year, as a standing budget line instead of a scary cluster. Two refinements make it sing: smooth the humps — fleets bought in bursts (the 2022 office refresh) age in bursts; spread the replacements a year early/late to flatten the spend · and attach replacements to natural moments — new hires get new machines while their predecessors’ units retire or become the loaner pool, the office move replaces what shouldn’t be paid to travel, the OS deadline replaces what can’t upgrade. Retirement is part of the cycle too: drives properly wiped or destroyed, the inventory updated, and the departing machine’s warranty and support status closed out.

Making it a rhythm

The whole practice compresses into the annual planning pass: the aging report reviewed (in a managed relationship it should arrive quarterly without asking), next year’s replacements named by quarter, the budget line confirmed, and the deliberate stretches re-justified annually — because “we decided to run it one more year” is a plan, and “it’s still working” is a countdown. The payoff reads like the absence of news: no surprise capital requests, no deadline-week hardware deaths, a fleet young enough to manage and patch cleanly, and an insurance application that answers “any end-of-life systems?” with a clean no.

The bottom line

Hardware publishes its own retirement schedule; lifecycle planning is just agreeing to read it. Realistic lifespans, a rolling replacement budget from simple division, replacements attached to natural moments, and the stretches chosen consciously — an afternoon a year that converts the most predictable failures in IT from emergencies into line items. The machines were always going to be replaced. The only question was who picked the date.