System Decommissioning : the process
The following picture gives an overview of the elements to be considered when decommissioning an IT application:
Hardware: Hardware refers to the technical platform on which the application to be decommissioned is running. The technical platform must not be limited to the computers on which the application is running, but also include networking and telecommunication devices, printers, network and security parameters (dedicated IP addresses, firewall rules, …)
Actions: Keep the platform, reuse for another purpose, sell, return to the supplier, stop the leasing contract, adapt parameters …
Software: References the application itself, as well as any software component the application needs in order to run (e.g.: Operating System, Compilers, IDE (Integrated Development Environment), RDBMS, Java, .Net, internal frameworks or libraries, other commercial packages, …).
Actions: Backup the source code, backup the operating system and dependent components.
Data: The data required to run the system, as well as the data created by the system.
Actions: Backup the data in its native backup format (ex: db dump), backup the data in a readable and reusable format (text file, xml, pdf, …)
Documentation: Business and technical documentation. This topic is often underestimated, however, it is not uncommon to refer to Business specifications to obtain a detailed description of a complex algorithm or business rules
Actions: Backup the documentation in its native format as well as in an open format (ex: pdf)
Replacing Systems: The system that will replace the decommissioned application.
Actions: A dedicated project must be created for this topic. Besides traditional IT project aspects, this project must also cover Change Management aspects. This is not covered in this document.
Auxiliary Systems: Refers to any system that makes use of the resources supplied by the decommissioned application, these resources might being API’s, Data Extracts, the Database(s). Common examples are Data-Warehouses, Reporting tools, Business Process Automation applications, Users spreadsheets, …
Actions: Identify all auxiliary systems (this usually requires a survey with the users), and for each, define a strategy: to be replaced or to be decommissioned.
For the ones to be decommissioned, apply the same decommissioning methodology described in this document, i.e., evaluate the technical, legal, commercial and human resources impacts.
Internal IT Resources: IT Employees fully or partially dedicated to the system.
Actions: Anticipate their assignment after the system is decommissioned. It is important to consider the technical and business knowledge acquired while working on the system, which could be reused in another project, or could be used as support to the replacing system. These actions must be performed soon enough in order to avoid employees being frustrated of not knowing their future.
External IT Resources: External contractors fully or partially dedicated to the system.
Actions: Consider if the contract must be extended or terminated. It is important to consider the technical and business knowledge acquired while working on the system, which could be reused in another project, or could be used as support to the replacing system.
For contractors planned to stay in the organisation, notify soon in advance the intention to extend the cooperation in order to avoid having contractors to accept another assignment.
For contractors planned to leave, ensure:
- all the critical knowledge has been transferred to internal resources
- contract ending is planned and negotiated (if needed) soon in advance
End-Users: Users of the application.
Actions: If the application is being replaced, ensure the proper training is given.
Actions: Please refer to the “Replacing Systems” actions.
Software Licensing: Refers to any legal obligation of the use of the application, the software ownership, …
Actions: Contact the vendor and notify soon in advance the intention to disrupt the contract. Identify with the vendor specific actions to be performed (ex: destroy all source code, return license keys, …)
Legal Reporting: Refers to any legal obligation to disclose information.
Actions: Ensure that the replacing system fulfils the legal obligation, as well as being capable to supply historical information from the decommissioned system
Supplier Contracts: Refers to contractual agreements to support the system, or one of its dependent systems. Typical examples are maintenance contracts, Data suppliers, telephony, web-hosting, data-centres,
Actions: For each contract to be disrupted, contact the supplier and notify soon in advance the intention to disrupt the contract.