End-of-Life Server Hardware: Building a Spares Strategy
End of life is announced by manufacturers as a date. In practice it is a gradual process, and the point that actually matters is not when support ends but when parts stop being obtainable — which is usually years later and never announced at all.
This guide covers how to manage that window deliberately rather than discovering it during an outage.
Why working hardware stays in service
It is worth stating plainly, because "the manufacturer stopped supporting it" is not by itself a business case for replacement.
Servers of the IBM System x and HP ProLiant G-series generations were over-specified relative to what most workloads needed. A machine running a file share, a domain controller, a departmental application or a disaster recovery target is doing a job it does perfectly adequately.
Some platforms go further. HP Integrity systems run HP-UX, OpenVMS and NonStop applications that are decades old and deeply integrated, where migration is a project with real risk attached. Organisations running them have usually costed it and concluded that keeping the platform alive is cheaper and safer, at least for now.
The same applies to storage. NetApp Fibre Channel shelves holding data that has not needed to move are a rational thing to keep running.
None of that is negligence. It becomes a problem only when nobody has worked out what happens when a part fails.
The three dates that matter
End of sale. The manufacturer stops selling the platform. Nothing changes operationally.
End of support. Warranty and support contracts end. Firmware updates stop. This is the announced date and the one people plan around.
End of parts availability. The real constraint, and it is never announced. Parts remain obtainable from the secondary market for years after support ends, and then the pool shrinks until it does not.
Planning around the second date while ignoring the third is the common mistake. A platform can be out of support for years and perfectly maintainable, then become unmaintainable quite quickly.
Building a spares position
This is the practical core of managing an end-of-life platform, and it is not complicated.
Step one: know what is actually fitted. Pull a drive from each chassis and record the part number. Photograph the label including the carrier. Do the same for any other consumable part. This takes an afternoon across a fleet and it is the single highest-value thing you can do, because part numbers are the only reliable way to source a match.
Working from the server model is not enough. The same model may have shipped with different carrier generations depending on when it was configured, and our compatibility guide exists because that distinction decides whether a drive physically seats.
Step two: count your exposure. For each part number, how many are in service and how many spares do you hold? A production system with zero spares of a discontinued part depends on market availability at the exact moment of failure, which is not a plan.
Step three: weight by consequence. A drive failure in a disaster recovery target is inconvenient. A drive failure in the array under a production application is not. Hold spares where the consequence is high, not evenly across everything.
Step four: check the spares still match. Part numbers change over a platform’s life. A spare bought three years ago may not match what is fitted today if drives have been replaced in between.
Hot spares and cold spares do different jobs
Worth separating, because they are not alternatives.
A hot spare is installed in the array and configured, sitting idle. When a member fails the controller brings it in automatically and the rebuild starts immediately — not when somebody reads the alert. On an unattended system that difference can be days.
A cold spare is a drive on the shelf. It restores full protection after the hot spare has been consumed, without waiting for delivery.
On a platform with no supply channel, the cold spare is the one that matters most, because the recovery path is market availability rather than a supplier commitment.
The maintenance window multiplier
One factor that changes the calculation significantly on older hardware.
If the chassis uses simple-swap bays rather than hot-swap, replacing a drive requires powering the server down. That means an outage window, approvals and scheduling — and the array sits degraded throughout the arranging, not just the swapping.
A drive that fails on a Friday might not be replaced until the following weekend. That is a week of running without redundancy on hardware whose drives are all the same age.
Where that is the case, double parity stops being an upgrade and becomes the sensible default. Our RAID guide covers the trade-offs.
Ageing arrays fail together
The risk that most maintenance plans underweight.
Drives bought and installed together share manufacturing batch, operating conditions and accumulated running hours. When one reaches wear-out, the others are at the same point in their service life.
Then a rebuild starts and every survivor is put under sustained read load for hours — the hardest work an old drive will ever do. Second failures during rebuild are not unusual on hardware this age.
Two responses. Move to double parity where you can. And on a system this old, treat the array as availability rather than protection: verify that your backups actually restore, because the probability of losing the array is materially higher than on newer hardware.
Setting a migration horizon
The point of all this is not to keep platforms alive forever. It is to make the end date a decision rather than an event.
Parts availability places a practical limit on any end-of-life platform. Planning a migration while spares are still obtainable leaves you with options: timing, budget cycle, phased cutover, proper testing. Being forced into one by a failure you cannot source leaves you with an outage and whatever you can arrange in a hurry.
A reasonable approach is to review annually: what is still in service, how thin is the parts market, what would migration cost, and what is the consequence of an unrecoverable failure. That review takes an hour and it is the difference between managing a platform and hoping.
Where refurbished fits
For end-of-life platforms it is usually the only source, and that is worth being clear about rather than framing it as a preference.
Manufacturers stopped producing these parts. Every unit in circulation came out of a system somewhere, which is why the pool shrinks over time and why buying a spare now is materially different from planning to buy one when it fails.
Enterprise hardware suits this well — metal chassis, sealed housings and internal shock mounting built for years of continuous operation, and mechanisms that do not degrade sitting in storage. Our refurbished process page explains condition labelling, testing and warranty in full.
We hold stock across IBM System x, Lenovo ThinkSystem, HPE ProLiant and MSA, HP ProLiant G-series and Integrity, and NetApp platforms. Send us your part numbers and drive counts and we will advise on a spares holding that matches the risk rather than quoting the list.
Common questions
Should I replace hardware as soon as it goes end of support?
Not necessarily. End of support is an announced date; end of parts availability is the real constraint and comes years later. A platform can be out of support and perfectly maintainable. What matters is whether you have worked out what happens when a part fails.
What is the single most useful thing to do for an EOL platform?
Record what is actually fitted. Pull a drive from each chassis, read and photograph the part number including the carrier. Working from the server model is not enough, because the same model may have shipped with different carrier generations.
How many spares should I hold?
Weight by consequence rather than holding evenly. A failure in a disaster recovery target is inconvenient; one in the array under a production application is not. Hold both a configured hot spare and a physical cold spare where the consequence is high.
Why does simple-swap change the risk?
Because replacement requires powering the server down, which means an outage window with approvals and scheduling. The array sits degraded throughout the arranging, not just the swapping — potentially a week. Double parity becomes the sensible default rather than an upgrade.
When should I actually migrate?
Before the parts market thins to the point where recovery is uncertain. Planning while spares are obtainable leaves you options on timing, budget and testing. Being forced by an unrecoverable failure leaves you with an outage and whatever you can arrange in a hurry.
Send us your platform, part numbers and drive counts and we will advise on a spares holding that matches the risk.
