What Is End of Life (EOL)?

End of life (EOL) is the point at which a manufacturer stops selling, updating, or supporting a product - the formal signal that an asset should be replaced or retired rather than relied on. It is declared by the vendor and applies to every owner of the product, which makes it different from useful life: useful life is your own estimate of how long an asset stays productive, while EOL is a date someone else sets.

EOL vs end of support vs end of sale

Vendors usually wind a product down in stages, and the labels are worth keeping apart:

• End of sale - the product is no longer sold new. Support, updates, and parts typically continue.
• End of support / end of updates - no more patches, firmware, or technical help. For software, this is the date that matters most.
• End of life - the umbrella term and usually the final milestone, after which the vendor has no remaining obligations.

The catch is that terminology is not standardised - one vendor’s “end of life” is another’s “end of support”, and EOS can mean either end of sale or end of support. The safe habit is to record the concrete dates per product rather than the labels.

Why EOL matters

Nothing breaks on the EOL date; what changes is what no longer happens. Software past end of support receives no security patches, so every newly discovered vulnerability stays open - which is why EOL operating systems show up in compliance audits and insurance questionnaires. For hardware, spare parts dry up, repairs get slower and dearer, and firmware bugs stay unfixed.

For equipment whose safe operation depends on the manufacturer, EOL bites harder still. Care and medical assets such as wheelchairs and hospital beds are often retired not because they stop working but because parts and authorised servicing for the model are discontinued, and a mandated inspection schedule cannot be met without them.

EOL for hardware vs software

Software EOL is sharp: a published date after which no patches ship, full stop. Hardware EOL is gradual - parts get scarce, third-party repairers fill the gap for a while, then even they run out. The two interact, too: hardware is frequently forced into retirement because the software it runs, or the OS it needs, has gone EOL first. An asset can be physically sound and still be end of life - which is also why refurbishment helps with worn hardware but cannot rescue unsupported software.

Planning replacements around EOL

EOL planning is mostly a recording discipline: capture the relevant dates when the asset is purchased, hold them on the asset record, and periodically ask the register one question - what reaches end of life in the next budget cycle? That turns EOL from a series of surprises into a staggered, budgeted refresh, and gives time to plan decommissioning properly instead of in a rush. In AMPthilly, each asset record carries the purchase date, warranty end, and expected useful life, and the register’s filters support exactly this kind of end-of-life and replacement planning, with a CSV export for the finance side.

Related terms

• Useful Life - your own estimate of an asset’s productive years, as opposed to the vendor’s EOL date
• Asset Decommissioning - the controlled retirement process EOL should trigger
• Refurbishment - a way to extend hardware life, when parts and support still exist
• Calibration - accuracy servicing that becomes impossible once vendor support ends
• Inspection Schedule - the recurring checks that often force the EOL decision on regulated equipment