Establish and Document Application Instance Decommissioning

This chapter explains how to establish and document the Decommissioning of an Application Instance, including the information that must be captured when a Decommissioned Instance continues to run.

Definition

Application Instance Decommissioning, often shortened to Application Decommissioning or Decommissioning, is the permanent removal of an Application Instance from its primary purpose within its IT Operating Environment Instance. A Decommissioned Instance may remain installed and running in a restricted capacity until it is Torn Down, for example to provide access to historical data for a required compliance retention period, or as a fallback while a replacement Application becomes adequately stable.

Why Decommissioning Is Not the Same as Shutting Down

Decommissioning removes an Instance from its primary purpose; it does not necessarily switch it off. Decommissioned Instances that keep running are common, and they are risky if their status is unclear: they may still hold sensitive data, still have user accounts, still need patching, and still cost money, while no one remembers why they exist or when they can be removed. Enterprises vary in the lifecycle status they assign to such Instances, for example “Deprecated” or “Retired”. Where “Retired” is used for an Instance, it should not be confused with the Retired status an Application receives only after Full Application Retirement. What matters most is that the status is recorded clearly and the reasons are documented.

Establish Instance Decommissioning

When an Instance is to be Decommissioned, establish, with the Application’s owners and Application Manager:

• Why: the reason for Decommissioning, and, if the Instance will keep running, why, such as compliance retention, access to historical data, or fallback while a replacement stabilizes.

• Who: who may still access the Instance, and how, for example read-only access for a named group, and who remains responsible for it.

• When: the Decommissioning date, the date until which the Instance must remain available, such as the end of a retention period, and the planned Tear-down date.

• What changes: the restrictions applied, such as disabled updates, removed Integrations, reduced user access, and adjusted monitoring and support.

• Data: how the Instance’s data will be retained, archived, migrated, or disposed of.

Document and Share the Decommissioning

Record the Decommissioning, with its why, who, when, restrictions, and data handling, in the Application Documentation, and update the Instance’s status in the documentation and, where Instances are listed, in the Application Record. Notify affected users, support teams, and owners of dependent Applications. Review Decommissioned Instances periodically to confirm they are Torn Down on schedule.

Best Practice: Establish and Document Application Instance Decommissioning

It is a best practice to both establish and document the solution for removing an Instance from service: record why it is being Decommissioned, why it may keep running, who may still use it and how, when it will be Torn Down, what restrictions apply, and how its data is handled.

Benefits: Capturing why, who, and when for each Decommissioned Instance prevents forgotten Instances from lingering indefinitely with sensitive data, open access, and ongoing cost. It also ensures compliance with retention obligations, because the reason an Instance is kept, and the date it may be removed, are known.

Connections to Related IF4IT Practices and Inventories

The Application Portfolio Management (APM) Best Practices addresses retiring applications properly by notifying users, migrating data, and decommissioning cleanly. The IT Operating Environments Best Practices addresses decommissioning environments deliberately.