TL;DR
Windows 10 reached end of support on 14 October 2025. Plenty of fleets did not finish before that date, and the refresh backlog that remains is now a quiet liability rather than a deadline anybody is shouting about. The work is the same as it was. The urgency has gone, which is exactly why it stalls.
- The deadline passed on 14 October 2025. The backlog did not pass with it.
- A post-deadline backlog is harder to resource, because the pressure is off.
- Size it by machines that cannot upgrade, not by machines not yet upgraded.
- Hardware eligibility is the real constraint. Some devices simply cannot move.
- Sequence by exposure, not by age or by department convenience.
- The lesson for next time: tie refresh to hardware eligibility, not to a date.
What a refresh backlog looks like after the deadline
Before a support deadline, the work has a date attached and everybody agrees it matters. Afterwards it becomes a risk register entry, and risk register entries move slowly.
The machines are the same machines. What changed is that nobody is asking about them weekly, and the budget conversation has moved on to next year’s priorities.
Best tools for Device Management
So the typical state thirteen months on is a tail of devices that were always going to be the hardest: the ones that cannot take the newer operating system, the ones belonging to people who kept deferring, and the ones nobody can locate.
Why the tail is the hard part
The easy machines went first. Everything remaining has a reason it did not move, and that reason is usually hardware eligibility rather than scheduling.
That matters because an upgrade project and a replacement project are different things with different budgets. Teams that planned an upgrade and discovered a replacement halfway through tend to stall at exactly this point.
Under ISO/IEC 27001, the information security management standard an unsupported operating system is normally treated as a control gap rather than a maintenance item, which is also why this shows up in customer security questionnaires long after the deadline has faded internally.
Sizing the refresh backlog honestly
The number most teams quote is machines not yet upgraded. That is the wrong number because it mixes two very different populations.
| Group | What it needs | Cost shape |
|---|---|---|
| Eligible, not yet done | Scheduling and a reboot window | Time only |
| Not eligible | Replacement hardware | Capital, per device |
| Cannot be located | Retrieval, or writing off | Unknown until found |
Split the list into those three before taking anything to finance. The conversation changes completely, because group two is a purchase request with a number attached and group one is a scheduling problem that needs no money at all.
The third group is the uncomfortable one
Machines nobody can locate are not a reporting inconvenience. Each one is a device that may still hold company data, running an operating system no longer receiving security updates.
Most of them are with people who left. Some are in drawers. A few were never returned after a repair. Whatever the cause, they belong in the backlog as their own line rather than being quietly excluded because they spoil the percentage.
Getting them back is a retrieval problem rather than an upgrade one, and collection from former employees is the mechanism. Worth stating the limit: retrieval recovers the device, and it will not tell you what was on it or whether it was encrypted, which is a separate question your management platform should answer.
Sequence by exposure, not by age
Disclosure: RemoAsset, named below, is owned by the same people who publish HROpsLab. It is described with its limitations stated, on the same terms as every other supplier. This site takes no vendor money and sells no placements.
The instinct is to work oldest first. It feels orderly and it is the wrong order.
Sequence by what the machine can reach. A five year old laptop used for scheduling in a warehouse is a lower risk than a three year old one with production access and a director’s mailbox on it.
Three factors decide the order.
- Data reachable from the device. Customer data, production systems, finance.
- Network position. A machine on an office network with broad access versus one that only reaches cloud services.
- Who holds it. Roles that attract targeted attention move earlier.
Reordering on those three usually moves a handful of devices to the front that nobody had flagged, and pushes back a larger group that was only ever prioritised for being old.
What to do with the ineligible machines meanwhile
They cannot be upgraded and they will not all be replaced this quarter. So reduce what they can reach rather than leaving them as they are.
Narrow network access, remove standing credentials, restrict them to a defined task. None of that is a fix and all of it buys time, which is what a backlog actually needs.
When they are finally replaced, they still carry data and still need a certified wipe. NIST Special Publication 800-88 on media sanitization is the usual reference, and an end of life machine running an unsupported operating system is not exempt from it.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| No idea of the number | Any | No fleet reporting | Cannot size the problem | Split the list into the three groups |
| Mostly eligible machines | Any | Upgrade stalled | Scheduling only | Book reboot windows, no budget needed |
| Large ineligible group | 50 to 200 | Older hardware | Capital request required | Quote replacements, sequence by exposure |
| Devices unaccounted for | Distributed | Register unreliable | Unknown exposure | Retrieval first, then assess |
| Security questionnaire arrived | Any | Backlog undocumented | Cannot show a plan | Document the three groups and the dates |
Getting a post-deadline backlog funded
This is where most remaining backlogs actually die. Not for technical reasons, but because the funding case was easy before the deadline and awkward afterwards.
Before, you could point at a date. Now the request sounds like asking for money to fix something that was supposed to be finished, which nobody enjoys presenting.
Three framings that work better
Frame it as the replacement cycle it always was. The ineligible machines were going to need replacing regardless. The operating system change revealed the timing rather than creating the cost, and presenting it that way moves it from remediation into normal capital planning.
Attach it to a commercial consequence. If a customer questionnaire has asked about unsupported systems, that is a far stronger argument than a risk score. One deal held up by a security review does more than six months of internal advocacy.
Ask for the smallest honest number. Separate the machines that must move this quarter from those that can wait two. A smaller request with a clear boundary gets approved; a full fleet number gets deferred for analysis.
The framing to avoid is the one most teams reach for, which is a percentage of compliance. Nobody funds a percentage. They fund a specific group of machines with a specific reason attached, and the three groups from the sizing exercise give you exactly that.
Not repeating it
Operating system deadlines arrive every few years and the pattern repeats because refresh is tied to the wrong thing.
Most refresh policies are tied to age. Three years, four years, whatever the finance assumption is. Age is a proxy and it correlates poorly with whether a machine can run the software you will need.
Tie it to eligibility instead. When you buy, record whether the device meets the requirements of the next operating system version, not only the current one. That single field turns the next deadline into a report rather than an audit.
The second change worth making
Track the ineligible count as a standing number, reviewed quarterly, rather than discovering it when a deadline is announced.
A fleet where the ineligible count is known and shrinking is in a different position from one where it is unknown, even if the two have the same machines. The first can answer a customer questionnaire. The second starts a project.
Where devices are bought through a single supplier against a defined specification, eligibility is recorded once at purchase rather than reconstructed later, which is part of what asset tracking tied to procurement gives you. It does not help with machines already in the field, which still need a one-off audit.
Finally, align the refresh assumption with the accounting one. If the useful life in your books under IAS 16 on property, plant and equipment says four years and your eligibility data says three, one of those numbers is going to be wrong in public.
For the budget side of that, see our guide to device budget per employee.
See eligibility recorded at purchase with asset tracking built into procurement, or read our guide to device budget per employee.
Frequently asked questions
When did Windows 10 support actually end?
14 October 2025. That date has now passed, which changes the nature of the problem rather than removing it. Before a deadline the work has urgency attached and everybody agrees it matters. Afterwards it becomes a risk register entry competing with next year’s priorities, which is precisely why remaining machines stall at this point rather than earlier.
How should we size the remaining backlog?
Split it into three groups rather than quoting one number. Machines that are eligible and simply not yet done, which need scheduling and no money. Machines that are not eligible, which need replacement hardware and a capital request. And machines nobody can locate. Those are three different problems and presenting them as one figure guarantees the conversation goes nowhere.
What about devices we cannot find?
They belong in the backlog as their own line rather than being excluded because they spoil the percentage. Each is a device that may hold company data while running an operating system receiving no security updates. Most are with people who left, some are in drawers, a few never came back from repair. Recovering them is a retrieval problem, not an upgrade one.
Should we upgrade oldest machines first?
No. Sequence by exposure instead, which usually produces a different order. A five year old laptop used for warehouse scheduling is lower risk than a three year old one with production access and a director’s mailbox. Rank on what data the device can reach, its network position, and who holds it. That reordering typically moves a handful of unflagged devices to the front.
What do we do with machines that cannot be upgraded?
Reduce what they can reach while they wait, since they will not all be replaced this quarter. Narrow network access, remove standing credentials, and restrict them to a defined task. None of that is a fix and all of it buys time, which is what a backlog needs. When they are finally replaced they still hold data and still need a certified wipe.
How do we avoid repeating this at the next deadline?
Tie refresh to hardware eligibility rather than to age. Most policies use a three or four year age rule, and age correlates poorly with whether a machine can run the software you will need. Record at purchase whether the device meets the requirements of the next operating system version, not only the current one, which turns the next deadline into a report rather than an audit.
Why does this still come up in security reviews?
Because an unsupported operating system is generally treated as a control gap rather than a maintenance task, so it appears in questionnaires long after the deadline has faded from internal attention. A fleet with a known and shrinking ineligible count can answer that question. One where the number is unknown has to start a project in the middle of a sales cycle.
