Workstation refreshes are the least glamorous program IT runs and one of the most important. Done well, nobody notices. Done badly, every helpdesk metric gets worse for a year. Over more than a decade at the same manufacturer I ran several full refresh cycles across office laptops, plant-floor desktops, and quality-lab workstations, and the pattern that kept them quiet was the same every time.
What the program actually had to solve
The easy version of this is that old machines are slow, so you buy new ones. The real version had more edges. Each cycle had to replace hundreds of devices across multiple plants and the corporate office without pulling anyone off the line, and it had to handle a mix of form factors an office-only shop never sees: ruggedized shop-floor PCs, quality-lab stations tied to specific instruments, kiosks, and the usual laptops and desktops. It also had to fold in whatever security and platform improvements the cycle made possible, things like TPM, BitLocker, modern Windows, and current management tooling, without turning the rollout into a referendum on any one of them. And it had to stay inside a predictable budget envelope so finance could plan, which is the reason it ran as a rolling refresh rather than a single capital event.
How the cycles actually ran
I treated the refresh as a continuous operation rather than a project with a start and end date. New machines arrived on a regular cadence, old machines aged out predictably, and the imaging and deployment process got a little better with every batch.
A few things made it work. Each role, office user, plant floor, lab, leadership, had a standardized configuration, so support and spares stayed finite instead of sprawling. Imaging was automated through Configuration Manager, with task sequences that handled OS deployment, driver injection, application install, and domain join in a single pass, so a machine went from box to ready-to-hand-off without anyone touching it past power-on. User data was migrated in the background ahead of the swap, so the actual at-the-desk time was minutes rather than hours. And the swaps were scheduled around people rather than around IT: plant-floor machines changed at shift changes, and office machines were swapped while the user was in a meeting so they came back to a working desk. Old hardware was wiped, tracked, and dispositioned off the books, so nothing wandered into a closet for the next person to inherit.
Where the security work hid
A refresh cycle is the cheapest moment to land platform changes that would otherwise need a project of their own. Every cycle quietly carried a security upgrade or two with it: TPM-enforced BitLocker, modern Windows builds replacing legacy versions, LAPS coverage on the local admin account, current EDR baked into the image, and removal of standing local admin wherever it could be removed. None of those needed its own change request, because it rode along with the hardware swap.
Why it was worth doing right
The visible outcome of a workstation refresh is that nobody complains for a while. The invisible outcome is the one that matters to the business: the whole fleet stays inside a known configuration, the helpdesk stops carrying a long tail of one-off machines, and the security baseline moves forward by default instead of by exception. Treating refresh as ongoing maintenance rather than a periodic emergency is what keeps the rest of the program from getting expensive, and it is what lets finance treat endpoints as a predictable line instead of a recurring surprise.