K-12 Device Lifecycle: Building a Refresh Budget That Survives the Board

"Four-year refresh" is a habit, not a plan. The date that actually ends a device's useful life is the date its platform stops receiving security updates, and every major education platform publishes that date. Budgeting against a round number rather than the published date is how districts end up either replacing working hardware early or running unsupported devices on a student network.

For ChromeOS, Google's published policy gives devices ten years of automatic updates, and the detail that matters for procurement is the anchor: the ten years run from the platform release date, not from the date the district bought the device. A model that has been on the market for four years when you buy it carries roughly six years of updates, not ten. Devices released from 2021 onward receive the full period automatically; for older devices, Google has offered the ability to extend automatic updates to ten years from platform release. Look up the specific model's auto-update expiration before comparing quotes — two Chromebooks at the same price can differ by years of supported life.

For Windows, two dates are live right now. Windows 10 reached end of support on October 14, 2025. Microsoft's Extended Security Updates program lets commercial and education organizations continue receiving security updates for a maximum of three years past that date, but it is deliberately structured to be uncomfortable: it must be purchased a full year at a time, it is cumulative — buying Year Two requires paying for Year One as well — the per-device price doubles every consecutive year, technical support is not included, and devices must be running version 22H2 to be eligible. It is a bridge, priced to be a bridge.

The second Windows date is more specific to K-12. Microsoft has stated that support for Windows 11 SE — the education edition built for low-cost 1:1 devices — will end in October 2026, that no feature update will follow version 24H2, and that it recommends transitioning to a device supporting another edition of Windows 11. A district with SE devices in the fleet has a decision inside this budget cycle: whether the hardware can carry a full Windows 11 edition, or whether those units become the next cohort.

A fleet purchased in a single year is a fleet that expires in a single year. That is the structural reason large refresh requests keep getting deferred: the ask is lumpy, it arrives without warning from the board's perspective, and it competes with everything else in that one budget.

The fix is to split the fleet into cohorts and replace one cohort per year, so the annual figure is roughly level and predictable. Three or four cohorts is the usual shape. The cohort boundary should follow something operationally meaningful — a grade band, a building, an incoming-class year — rather than an arbitrary serial-number split, because the boundary also determines who gets the new devices and that is a conversation with principals, not with finance.

Getting from a single-year fleet to a staggered one costs money during the transition, and the honest way to present that is as a two- or three-year bridge with a defined end. Options include retiring the oldest third early, extending one cohort by a year where the support date allows it, or buying a partial cohort of renewed hardware to fill a single year. Refurbished enterprise hardware is a legitimate tool here — Joy Systems, for instance, supplies refurbished Dell OptiPlex and HP EliteDesk desktops and Dell and HP notebooks through our catalog — provided you check the platform support date the same way you would on a new unit, because a refurbished device with two years of support left is not a bargain.

Present the schedule, not the total. A board that can see year one, year two and year three, with the vendor date each cohort is anchored to, is being asked to approve a plan. A board shown one large number is being asked to approve a surprise.

Three costs recur every year of a device program and are routinely treated as one-time additions to a purchase order. Moving them into the base budget is what makes the schedule hold.

Spares. A device program without a spares pool is a device program where a broken screen costs a student two weeks of instruction. The pool has to be sized from your own damage data and refilled annually, and the funding line has to survive a year in which nothing dramatic happens — which is exactly the year it tends to get cut. Our spares and repair planning piece covers how to size it from ticket data rather than from an industry figure.

Repair. Whether repairs happen in-house or at a depot, they cost money every year: parts, labor, shipping, or a service contract. Decide the model deliberately and budget it as an operating line.

Disposition. Devices leaving the fleet have to be sanitized, documented and disposed of responsibly, and that has a cost whether or not it produces residual value. Treating disposition as an afterthought is how districts end up with three years of retired devices in a storage room, which is both a liability and a deferred bill. Budget it against the cohort that is leaving, in the same year the replacement cohort arrives.

The arithmetic here is simple and it is the single most useful thing to put in front of a board. Divide the device price by the number of supported years remaining on its platform, and compare the results rather than the sticker prices.

A device that is cheaper today but sits on a platform with four years of updates left, against one that costs more but carries eight, is very often the more expensive purchase per supported year — and it also forces a second refresh inside the planning window, which is a bigger problem than the price difference. This is exactly why the ChromeOS anchor matters: because auto-update expiration is measured from platform release, buying a model late in its market life quietly shortens the denominator.

Two caveats keep this honest. First, the calculation compares supported life, not suitability — a device that is too slow for the district's software in year five is finished regardless of what its support date says. Second, we sell hardware, so the version of this argument that favors the more expensive unit is the version that favors us; the reason to trust the method is that it is arithmetic you can run yourself against published dates, not a recommendation you have to take on faith.