The decommissioning of applications can be a significant burden for an enterprise, especially one that has tended to update and upgrade or replace existing applications without properly retiring older ones.
Companies face many different challenges in decommissioning large numbers of applications. Many of them are related to giving the new applications the functionality that they need, and making sure that older applications are actually “dead” or ready for retirement.
Gartner estimates that from 2016 to 2020, stakeholders will decommission three times more than the total number of applications decommissioned in the last 16 years. There is a feeling that businesses have in general delayed or deferred decommissioning, often at their peril.
Often dealing with fairly complicated architectures, businesses must be sure, as mentioned above, that new applications are fully provisioned before retiring or decommissioning one that is considered obsolete. Otherwise, the company may have to go back and rely on the legacy application when the new one fails, or is not able to handle demands that are placed on it. At the same time, trying to decommission an old application without total cessation of use and data extraction can have its own problems. There is the issue of making sure that sensitive data is handled well, and in some cases, extracting all of the data from the old application can be difficult.
In other cases, companies retain data in the old system for archive use – for things like e-discovery or industry compliance. Then there’s the burden of maintaining access to the old application.
In order to plan the decommissioning of applications well, companies might use a decision matrix or other resource to look at various issues, from licensing to user experience to specific functionality in business processes. Gartner recommends appointing an “undertaker” or point person or team to decommission applications. The general sense is that companies should invest more time and effort into planning decommission, and understanding their architectures better, so that they can more efficiently add, subtract or change applications according to real operational requirements, and not blindly.