Hardware Refresh Cycles: The Great Debate

Three years, four, or five? Three curves you can measure in your own environment — and why the confident numbers are the least trustworthy.

Somebody in your organization decided how long a laptop lives. Ask where that number came from and you'll usually get "it's industry standard," "that's what the lease term was," or a long pause. Meanwhile it quietly determines a seven-figure line item every year.

This episode doesn't hand you a number. It hands you a method. The Three Curves — failure, cost, and value — each measurable in your own environment from data you already have, and where they intersect is your refresh cycle rather than a vendor's.

Along the way: why the widely quoted refresh statistics don't survive being traced to their sources, what actually fails in a modern laptop and why it's cheaper to fix than you think, the residual value you forfeit by stretching a cycle, and how the Windows 11 hardware requirements turned refresh from a hardware question into a platform runway question.

Plus a listener question from Tony in Toledo, whose CFO wants to move from four years to six — and the argument that actually works in that meeting.

IN THIS EPISODE

- Why most refresh cycles have no documented origin
- The provenance problem: tracing the widely quoted statistics back to dated or vendor-funded sources
- Curve one — failure: what actually breaks in a modern laptop, and why it's rarely the drive
- Curve two — cost: building your own support-cost-by-age curve in an afternoon
- Why the cost curve turns upward exactly when the warranty expires
- Curve three — value: the residual recovery you forfeit by stretching the cycle
- Paying twice, in two different budgets, across an accounting seam
- How Windows 11 hardware requirements changed refresh from hardware to platform runway
- Buying for supported life rather than unit price
- The AI PC question, and whether NPU capability justifies acceleration
- Weeding the collection: why librarians never withdraw a book for turning four
- Segmenting the fleet — why one cycle is wrong for most of your users

CHAPTERS

• (00:03) - Refresh Debate Begins
• (02:22) - The Three Curves
• (04:09) - Failure and Cost
• (07:01) - Push Back with Data
• (07:22) - The Value Curve
• (08:46) - Security Changes the Game
• (11:01) - The Library Analogy
• (12:01) - Segment Your Fleet
• (12:39) - Refresh Is Economics
• (14:02) - Disposal Next Time

TRANSCRIPT
SOURCES & FURTHER READING

Microsoft — Windows 10 end of support
https://www.microsoft.com/en-us/windows/end-of-support

Microsoft — Windows 11 system requirements
https://www.microsoft.com/en-us/windows/windows-11-specifications

A note on evidence: the refresh statistics circulating in this field are unusually poorly sourced. Figures on failure rates and support costs for aging hardware typically trace back either to studies more than a decade old or to research funded by hardware manufacturers. This episode deliberately avoids quoting them. The Three Curves framework exists so you can measure your own environment instead of borrowing someone else's number.

LISTENER CASE FILES

Got a situation you'd like worked on air? Send it over — anonymized, sanitized, no company names. Real constraints, real politics, real budgets. operationalitam.com

ABOUT THE SHOW

Operational ITAM is a podcast about the unglamorous machinery of enterprise technology — hardware and software asset management, licensing, audit defense, SaaS governance, and the money quietly leaking out of all of them.

Bill Van Nort has led IT asset management, end-user computing, IT operations, and workplace technology at large organizations across banking, mortgage, and automotive. He has reclaimed millions in software spend and survived audits from the biggest publishers on the planet.

Consulting enquiries and listener case files: operationalitam.com

Creators and Guests

Host

Bill Van Nort

Founder of Operational ITAM. Thirty years leading IT asset management in banking, mortgage, and automotive.

What is Operational ITAM Podcast?

Thirty years of enterprise IT, distilled into something you can use on Monday morning.

Operational ITAM is a podcast about the unglamorous machinery of enterprise technology — hardware and software asset management, licensing, audit defense, SaaS governance, and the money quietly leaking out of all of them. Host Bill Van Nort has led IT asset management, end-user computing, and workplace technology at large organizations across banking, mortgage, and automotive, reclaimed millions in software spend, and survived audits from the biggest publishers on the planet.

No vendor pitches disguised as advice. No jargon for its own sake. When something is an opinion, he says so. When the honest answer is "it depends," he tells you what it depends on.

New episodes cover the fundamentals that never change: know what you have, know where it is, know what it costs, know when it leaves.

Hey, everybody, and welcome back to the Operational ITAM Podcast.

I'm Bill Van Nort, and today we're finally doing the episode I've been threatening

you with since the very first show.

The Great Refresh Debate. Three years, four years, five or more.

Everybody has an opinion.

The vendors have brochures. Your CFO has a number she'd very much like you to agree with.

And somewhere underneath all of that, there's an actual answer. Let's go find it.

Good morning, good afternoon, or good evening, wherever you're listening from.

This is the show where we take the unglamorous machinery of enterprise technology and make it make sense.

Grab your coffee. This one has math in it, but I promise it's the good kind. So here's the setup.

Somebody in your organization has decided how long a laptop lives.

Maybe it was written down. Maybe it was inherited. Maybe it's just what the last guy did.

And every year, that number quietly determines a seven-figure line item in somebody's budget.

Now here's the uncomfortable part. When I ask people where their refresh cycle

came from, I get one of three answers.

It's industry standard. That's what the lease term was.

Or my personal favorite. A long pause followed by, huh.

If that's you, don't feel bad. I've been that guy.

I've defended a four-year cycle in a budget meeting with total confidence and

absolutely no idea where the four came from.

So let's fix that today. Before I give you the framework, I want to be straight

with you about the evidence, because this is one of those topics where the confident

numbers are the least trustworthy ones.

You have probably seen a statistic, something like, older machines have some

specific percentage more security incidents, Or, devices past year 4 cost some

specific number more to support.

Those figures get quoted constantly. They show up in vendor decks,

in analyst summaries, and LinkedIn posts.

Chase most of them back to the source and you find one of two things.

Either a study that's a decade old, or a study funded by somebody who sells laptops.

That doesn't make them wrong. It makes them unverified.

And on this show, we say the difference out loud. So I'm not going to hand you

a number. I'm going to hand you a method.

And the method is the framework for today. I call it the three curves.

Here's the idea. There are three things that change as a device ages.

Each one moves in a predictable direction. Each one is measurable in your own

environment with data you already have.

And where they cross is your refresh cycle. Not mine, not Gartner's, yours.

Curve 1, the failure curve. Curve 2, the cost curve. Curve 3, the value curve.

Let's take them one at a time. Curve 1, the failure curve.

This is what most people think refresh is about. Hardware wears out,

hardware breaks, replace it before it breaks.

And that's true, but not the way most people assume.

Here's what actually fails in a modern laptop. It is almost never the storage.

Solid state drives have no moving parts, and in normal office use,

most of them will outlast the machine they're installed in.

If you're still refreshing on the assumption that drives die,

you're fighting a war that ended when spinning disks left the building.

It is almost never the processor. Silicon doesn't get tired.

What fails is the battery. Batteries are consumables, they are chemically guaranteed

to degrade, they degrade by charge cycle rather than by calendar,

and they are the single most common reason a user tells you their laptop is dying.

And after batteries, it's the mechanical stuff. Hinges, ports,

keyboards. Anything a human touches a thousand times a day.

Now, why does that matter?

Because two of those three are repairable, and one of them is a $40 part.

So the failure curve is real, but it is flatter than the vendors would like

you to believe, and a chunk of it can be bought down cheaply.

Keep that in your pocket, we're coming back to it. Curve two, the cost curve.

This is where it gets interesting, and this is the curve almost nobody actually measures.

Your cost curve has three components. Support cost, tickets, labor, parts.

Warranty cost, what you pay to cover the device and what you pay when it isn't

covered, and productivity cost, the hours your people lose to a machine that's

slow or down or being re-imaged.

The first two you can pull today. Your service desk has tick accounts.

Your asset system has purchase dates.

Join those two datasets and you have your own support cost by age curve in an afternoon.

No consultant required. No study required.

I've done this exercise in three different companies, and here's the pattern I've seen.

The cost curve is flat, flat, flat.

And then it isn't. It doesn't rise gently.

It sits still for a while, and then it turns upward, usually right around the

moment the standard warranty runs out. Which should tell you something.

A meaningful part of what people call aging hardware cost is actually,

we stopped paying for coverage and now every repair is a purchase order.

That is not a hardware problem. That is a contract design problem,

and it's a much cheaper problem to solve.

The third component, productivity, is the one everybody wants to quantify, and almost nobody can.

If you have a defensible way to measure the cost of a slow laptop,

I would genuinely love to hear it, and I'll put you on the show.

Until then, I treat productivity as a real cost that I cannot measure,

and I say so in the meeting.

That's more credible than a made-up number, and finance people can smell a made-up

number from the other end of the building.

Before we get to Curve 3, a listener question. This one is from Tony in Toledo.

Tony writes, Bill, our CFO wants to move us from a four-year cycle to a six-year cycle to save money.

I know it's a bad idea, but I can't prove it. How do I push back?

Tony, great question, and here's my honest answer. You probably can't prove

it, and you shouldn't try.

Here's why. If you walk into that meeting with a vendor statistic,

she will discount it, and she will be right to.

If you walk in with a productivity estimate, she'll ask how you calculated it,

and you'll be in trouble by the second follow-up question.

So don't argue the cycle, argue the curves. You'll get your own support cost by device age.

Real tickets, real labor, from your own environment.

Then show her where your curve turns upward. If it turns at year five,

a six-year cycle is a documented decision to operate on the expensive side of your own data.

If it doesn't turn until year seven, then she's right, and you just saved the

company money by checking.

And here's the part that matters. Bring her the residual value number two,

which is exactly where we're going next.

Because the strongest version of this argument isn't old laptops are bad.

It's we are throwing away recoverable value, and here is how much.

Finance people don't respond to risk. They respond to arithmetic.

Curve three, the value curve. Here's the one that gets left out of nearly every

refresh conversation I've ever sat in, and it's the one with actual money attached.

Your devices have residual value not much individually but at fleet scale it's

real and it declines on a curve that looks nothing like the other two resale

value falls fastest early.

A one-year-old business laptop is worth a meaningful fraction of what you paid.

A three-year-old machine is worth noticeably less.

By year five or six, in most segments, you're near the floor.

The difference between a five-year-old device and a six-year-old device is close

to nothing, which produces a genuinely counterintuitive result.

Stretching your cycle from four years to six doesn't just add two years of higher

support cost, it also gives up almost all of the resale recovery you'd have captured at four.

You pay twice, once on the way through and once on the way out.

I have watched organizations extend a refresh cycle to avoid a capital expense

and then dispose of the entire fleet for scrap value two years later.

Nobody connected the two decisions because the savings landed in one budget

and the loss landed in another.

And by the time the second thing happened, the person who made the first decision had moved on.

That is not a technology failure. That is an accounting seam.

And finding those seams is a lot of what this job actually is.

Now, let me overlay the thing that has quietly taken over this entire debate. Security lifecycle.

For most of my career, refresh was a hardware conversation. It isn't anymore.

Today, the thing that most often forces a device out of service is not that

it broke. It's that it can no longer run a supported operating system.

Windows 10 reached end of support in October of 2025, and the hardware requirements

for Windows 11, TPM 2.0, plus a supported processor list meant a large number

of perfectly functional machines became ineligible.

Not slow. Not broken. Ineligible.

That is a very different kind of obsolescence, and it does not care about your curves.

So here's the practical implication. Your refresh cycle now has a hard ceiling

that is set by somebody else, in a decision you don't control,

on a timeline you find out about after the fact.

Which means the question isn't only, how long can this device last?

It's, how much runway does this device have left on a supported platform?

And that is a question you should be asking at purchase, not at end of life.

Buy the machine that has the longest supported life ahead of it,

not the cheapest one on the sheet.

Two years of platform runway is worth more than $100 of unit price.

Quick word on the AI question, because I get it constantly. Should you accelerate

your refresh to get NPU-equipped machines?

The current bar for the branded AI-capable devices sits somewhere around 40

tubs of neural processing, and that number will have moved by the time you hear this, so check it.

My honest answer, and I'll flag this as an opinion, no, not on its own. Not yet.

If your users have a specific workload that runs locally and needs that silicon,

buy for it deliberately.

But accelerating a whole fleet refresh to acquire a capability that most of

your users have no current workload for is buying a feature and hoping demand shows up.

The counter argument is real though, and I'll give it to you fairly.

If a device you buy today lives four or five years, you are making a bet about

what workloads look like in 2030.

Buying some headroom is defensible. Just call it what it is,

a bet, rather than dressing it up as a requirement.

All right, let's talk about the library, because we've been building this metaphor

all season, and it fits today better than it has fit anything yet.

Libraries have a formal process for this. It's called weeding.

Sounds brutal, and librarians hate the word, but it's a real discipline with

real criteria—condition, circulation, currency, and whether the item still serves the collection.

Notice what's not on that list.

Age. A librarian does not withdraw a book because it turned 4.

They pull it because it's falling apart, because nobody's checked it out in

years, because the information in it is out of date, or because they need the shelf.

That's exactly the right model. A refresh cycle based purely on the calendar

is the equivalent of throwing out every book on its fourth birthday,

regardless of condition or use.

It is simple, it is defensible in a meeting, and it is wrong at both ends.

You're replacing perfectly good machines, and you're keeping bad ones.

Which brings me to the single most useful thing I can tell you today.

Stop having one refresh cycle. Segment your fleet.

A task worker on a shared floor terminal, a developer compiling all day,

a sales engineer living out of a bag in an airport, and an executive who reads email.

Those are four completely different failure curves, four different cost curves,

and four different value curves.

One number for all of them is guaranteed to be wrong for at least three of them.

Start with two segments, just two, heavy use and light use.

Even that crude split will beat a single fleet-wide number, and you can build

it from data you already have.

So, the principle for today.

We've been stacking these up all season. Hardware asset management is about

custody. Software asset management is about evidence.

Audit response is about process.

Audit settlement is about commerce.

Shadow IT is about service.

Refresh is about economics. Not about hardware, not about how long a laptop

can technically survive, because the answer to that is almost always longer

than you think and longer than you should keep it.

It's about where three curves intersect in your specific environment and about

having the arithmetic to defend the answer when somebody with budget authority asks you why.

The person who can show their work wins that meeting every time. All right.

Your takeaway ticket. This week,

pull two lists. One, every device in your fleet with its purchase date.

Two, every service desk ticket from the last 12 months with the device attached. Join them together.

Count tickets per device by age and years. That's it. That's the whole assignment.

You will have your own cost curve by Friday, built from your own data,

and you will know something about your environment that nobody else in your organization knows.

And here's my promise. Whatever that curve tells you, it will not match the

number you're currently using. It never does.

Class dismissed. Next episode, we're going to the end of the line.

Disposal, data destruction, and chain of custody.

The last mile, where the risk concentrates and where I have some genuinely alarming

stories about hard drives turning up at flea markets.

If you've ever signed a certificate of destruction without reading it, that one's for you.

One more thing before I go. I promised you listener case files back in episode one, and I meant it.

If you've got a situation you'd like me to work on air, anonymized,

sanitized, no company names, send it over at operationalitem.com.

Real constraints, real politics, real budgets. That's the show I want to make.

I'm Bill Van Ort. This is the Operational ITAM Podcast.

Know what you have. Know where it is. Know what it costs. Know when it leaves.

I'll see you next time. Take care.