Software Removal Process

Jan 28 / Rory Canavan
Off the back of a post some time ago, someone asked me what was the difference between the software recycling process and the software removal process. I can see how it might be easy to confuse the two, however, they both appear at different points in the IT Asset lifecycle, and have slightly different goals.
Software Recycling Process' goal: To uninstall software with a view to reusing it at a later date;
Software Removal Process' goal: To uninstall software with a view to NEVER using this title ever again.

The consequences of removing a software title from our IT estate cascades a series of activities that we wouldn’t adopt if we were merely recycling software:
• A refresh of the status of that software title in the Supported Software Catalogue: ideally, we don’t remove the title, merely flag it as not suitable for use – we don’t want to run Office 2003 through the software approvals process just because someone happens to ask for it by name!
• Archiving of entitlement: if we no longer have active entitlement to apply to rogue installs, they will be flagged up as non-compliant, making them much easier to spot.
• Archiving of installer packages: You can’t install something if you don’t have the media. Archiving installer packages removes temptation to install it, whether it’s laziness, human error or it’s seen as a quick and easy way to solve a compatibility issue.
• Trigger the deployment process: the removal of a software title is the result of an upgrade or replacement activity with a newer/ more acceptable instance of software. Actively engaging in a removal process (as opposed to simply running the deployment process for the new title) ensures that you spot old software to be upgraded or removed that you may otherwise have missed.

At first glance, this could appear to be a lot of work and anyway, why aren’t Service Management accountable for getting rid of old software?! A mentality of “If ain’t broke, don’t fix it” could result in layers of software developing like plaque on your IT estate – creating nasty tech debt and management problems in the future. Think about it: we don’t just floss once a year!
Your ability to perform SAM well is governed by the resources at your disposal and how you can apply them to an ever-expanding IT estate. Being rigorous about running the Software Removal process provides you with some chance of limiting software sprawl so that your resources are not spread ever thinner and you’re storing up compatibility issues, high support & maintenance costs and information security risks as software gets older.
If your higher goals are to manage a lean and future-proofed IT estate, then the Software Removal process is every bit as vital as the Software Approvals process. IT not only makes SAM-sense, it makes fiscal, operational and info-sec sense also.

Created with