The end-of-support date for an operating system is known years in advance. Hardware vendors announce end of support well ahead of time. And yet the same scene keeps repeating in many organizations: a few months before the deadline, someone discovers dozens of servers running an unsupported version, and nobody knows exactly which services depend on them.
What follows is a scramble. Who owns this application? Can the server be upgraded, or does it need a migration? Who pays for it if it was never budgeted? The operations team spends weeks building an overview that should have existed all along. Meanwhile, the security manager has to explain why systems without security updates are still running in production.
Why a spreadsheet is not enough
The usual tool for tracking lifecycle is a spreadsheet. Someone built it once, filled in OS versions and end-of-support dates, and passed it on. The trouble is that a spreadsheet starts going stale the moment it is created.
- It is not linked to reality. A server gets upgraded or decommissioned, and the spreadsheet never hears about it.
- It is not linked to services. It lists servers, not what they are for. Without that, you cannot decide what comes first.
- It has no owner. When nobody is accountable for the data, nobody keeps it current.
The result is a list that answers “what is old?” but not “what is at risk, and for whom?”
How to approach lifecycle
Lifecycle is not a separate register. It is an attribute of items you already track. If your CMDB knows which operating system runs on a server and what hardware the server is, all you need to add is end-of-support dates, and you have an overview that updates with every change.
The second step is to connect lifecycle to services. An unsupported server carrying a critical business service is a very different priority from a test machine with no dependencies. Renewal decisions should follow service impact, not an alphabetical list of hostnames.
The third step is to look ahead. If you can see what reaches end of support in one or two years, you can put renewal in the budget, agree it with the service owner and carry it out in a regular maintenance window instead of an emergency project.
How Eywo Stratum handles it
Eywo Stratum tracks the lifecycle of operating systems, software and hardware directly on CMDB items. For every server you can see which version it runs and when support for that version ends. The overview shows servers already on unsupported versions as well as those approaching the deadline.
Because lifecycle is part of the CMDB, the data stays current. Items are populated through the discovery API, CSV or Excel import, or synchronization with a primary CMDB. Every change to an item is versioned with its history, so you can see when and from where an OS version changed. Data quality checks flag inconsistencies, such as a server with no operating system recorded.
The link to services is what matters most. The layered dependency map shows which applications and business services rely on a given server. From the end-of-support overview, you can move straight to the questions that count: which services are at risk, and who owns them. Renewal planning then starts with a conversation with a specific person about a specific service.
The renewal itself runs as a normal change: a change model, an impact calculation before submission, a slot in a maintenance window outside change freezes, and outage approval from the owner of the affected service. An OS upgrade does not skip the process just because it is urgent.
Conclusion
End of support does not have to be an annual firefight. When lifecycle lives in the CMDB and is connected to services, you see it coming, you know who is affected, and renewal can be planned calmly. Operations does not have to assemble an overview under pressure, and service owners learn about the risk in time.
Lifecycle tracking for operating systems, software and hardware is included in the Standard edition.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.