Hardware refresh cycle: intervals by device class and the budget arithmetic

Working intervals by device class

These are the intervals commonly used in MSP practice, not a published standard. Their value is that they are written down and applied consistently. Pick your numbers, put them in the policy, and use the same ones every quarter.

• Office desktops and standard laptops: commonly four to five years. Warranty is usually three, which means years four and five are carried at your risk unless you extend.
• Engineering, design and developer workstations: commonly three years, driven by software requirements rather than hardware failure.
• Field and mobile laptops: commonly three to four years, because physical wear rather than performance is the limiting factor.
• Servers: commonly five years, aligned to the end of extended warranty, and increasingly moot as workloads move off premises.
• Network switches and firewalls: commonly five to seven years for switches, but firewalls are governed by the vendor's software support end date rather than by age. A supported firewall is a security control and an unsupported one is a finding.
• Wireless access points: commonly five years, or sooner when a new standard changes what the client's devices can actually use.
• Phones and tablets: commonly three years, effectively set by the manufacturer's OS support window.

The signals that override the interval

An interval is a default, not a rule. These signals justify moving a device in either direction, and writing them into the policy is what stops the exceptions becoming arbitrary.

• Replace early: the device generates repeat tickets. A machine appearing three or more times in a quarter costs more in support time and lost user hours than the replacement does.
• Replace early: the OS or firmware is out of vendor support. This is a security decision rather than a lifecycle one and it should not wait for the interval.
• Replace early: the role changed. A machine that was fine for one job is not automatically fine for the next one.
• Replace early: the warranty has expired and the user cannot tolerate downtime. Out of warranty means your repair time is now the client's outage.
• Extend: a light-use device in a low-impact role with a healthy drive and current OS support. A reception machine that browses and prints does not need the same interval as a finance workstation.
• Extend: a device already scheduled for retirement with the role, such as a site closing or a team moving to a different platform within the year.

Turning the asset list into a budget

Five steps. This is the calculation behind the refresh line in a quarterly review, and the whole point is that it is arithmetic rather than opinion.

• Step one: get the age of every asset from its purchase or first-seen date, and the warranty end date alongside it. Note what percentage of assets are missing either field, because that percentage is the error bar on everything downstream.
• Step two: group assets by device class and apply the interval for that class to get a replacement year for each one.
• Step three: count the devices falling into the next four quarters, and count the devices already past their interval separately, because that backlog is a different conversation from the plan.
• Step four: multiply each class count by your current standard replacement cost for that class, including the build and deployment labour, not just the hardware. Date the cost table.
• Step five: phase the total across the four quarters and present it as a phased line. A client who rejects one large number will often approve the same total spread across a year.

The backlog conversation

Almost every estate has devices already past their interval, often a large share of them, and the instinct is to leave that off the slide because it looks like an accusation. Put it on. Show the count, show what it would cost to clear, and offer a phased path rather than a single number. A client who can see the backlog shrinking quarter by quarter is a client who understands what the refresh line is for. A client who only ever sees next year's plan will keep deferring it, and the backlog is what eventually turns into an incident.

Where the data usually lets you down

The arithmetic is easy. The inputs are where refresh planning actually fails, and it is worth checking these before presenting a number to a client.

• Missing purchase dates on assets added manually or inherited from a previous provider. Warranty lookup by serial closes most of this gap.
• Warranty data that was correct at onboarding and has never been refreshed since. Warranty status changes on its own, so it needs re-checking rather than storing once.
• Devices that exist and are not in inventory at all, which is the failure that flatters the report by exactly the size of the blind spot.
• A replacement cost table that has not been updated in a year, which makes an otherwise correct budget wrong by whatever hardware prices have done since.
• Assets belonging to a class you never defined, which end up on a default interval nobody chose.