Tideway is exploring the feasibility of providing end of life / support data to augment discovered data in order to help customers identify and track removal of unsupported server models and software products.

Please tell us if these additional attributes will be of value to you, sources of end of life data that you refer to and if there are any impending end of life products that are of interest to you.

From what I’ve seen, the issue is less the identification of the products by dates - there’s often an organisation specific extension in place anyway - but more the provision of visibility of the situation on an ongoing basis to drive elimination initiatives to conclusion.

The management of the long tail of older / niche products is a key win for Tideway enabled IT estate management. This type of asset consumes a disproportionately large part of the IT budget. Dashboard based management is what’s needed from Foundation, as we’ve seen some customers implement with Tideway data.

Steve - this would be of huge value to my client.  What I’d like to be able to do is produce a report/dashboard that ranked the various services that we support and be able to detail the percentage of service components that are either OOS or going OOS in x months.

Most larger vendors operate end of life polices and publish schedules but I do not beleive vendors publish this information in a consistent or standardised fashion, this could make it a challenge for Tideway to develop/maintain effective knowledgebases containing EOL information.

However, whether or not the knowledge is pre-populated, the facility to record and report on end of life attribues should be useful to most organisations for risk management and also to aid planning.

There would seem to be a number of relevant attributes to an end of life section of a software product record, including:

Obsolescense Date (the date the product ceased being current)
Superceded by (the product that replaced it, due to M&A;activity this may be a product of a different name, by a different vendor)
Primary support available until (most vendors provide a multi level end of life support model)
Extended support available until
Extended support restrictions
End of Life date
URL or UNC path reference to vendor EOL information

this is also a big issue in our project. I think the Attribut’s as Dave posted ar ok to generate usefull reports and manage the outdating Systems. how abou a selflearning List?
Scanned Systems stored in a unique list with additional Attributs. this would be enough to generate information.