practical-itam.co.uk

As we’ve seen, software deployment and upgrade maintenance functions tend to follow the same set of processes. We’ve also seen that because software is just code that can be updated and changed easily over a long period of time, it has a much longer lifespan than hardware does generally.

But software will come to the end of its life sooner or later. Often it will just become too difficult to continue updating it, so a completely new piece of software will be adopted. Other times the function for which it was originally designed is no longer required and so neither is the software. The mutually reinforcing technology cycle where more sophisticated hardware requires more sophisticated software which requires more sophisticated hardware also plays a part.

The decision that software is no longer required is generally an architectural one. By this I mean that the decision will be made by the people who manage the IT infrastructure of an organisation to ensure that it meets ongoing needs. The decision to discontinue a piece of software will be based upon input from users, tech support, and the developers who may have been upgrading the software.  Non-technology areas such as procurement and the Legal department may also contribute to the decision making process. Other things that will be considered are what alternatives are available and how much they would cost, both in terms of creating / purchasing the software in the first place, and also how much it will cost to maintain / update the software over time.

Once the decision has been made to remove a piece of software, the software needs to be uninstalled from machines. This can be either be a manual process – very time consuming – or it can often be done automatically using a software deployment tool – yes, these tools will generally be able to automatically uninstall software too!

Sometimes software can be difficult to uninstall, particularly if it is older, or hasn’t been designed well. Sometimes software can leave traces in the registry which can be difficult to remove, and older software, particularly, may never have been designed to have an ‘uninstaller’ which will remove the application from the machine without affecting other software. Thorough testing should always be conducted before a piece of software is uninstalled to ensure that the uninstall causes no problems. Occasionally software that does not uninstall properly will leave a ’signature’ in the registry or add/remove programmes which can fool a discovery tool into thinking the software is still installed. This can confuse licensing positions, and is another reason why thorough testing should be carried out before uninstalls go ahead.

Another big challenge faced when uninstalling software from an organisation is similar to one faced by Patch Management – the need to ensure that the software has been uninstalled from all required machines. As with Patch Management, software asset management tools can provide us with the information we need to check the uninstalls have been completed.

As with the situation where a discovery tool is fooled by poorly uninstalled software, software that we think has been uninstalled but is actually left on machines can have serious implications for the license position of the organisation.

This has just been a very quick run-down of some of the issues to take into account when software reaches its end of life. Next we’ll take a look at the finance implications of the software lifecycle, with a focus on how to manage licensing at each stage.

Picture Credit: Kylie Fowler