Application Decommissioning for Information Security, Step 6: Retire Applications

If your organization has gone through the five steps needed to prepare to decommission applications that are no longer needed, there remains one final critical task: the actual decommissioning of those applications that are no longer needed. Many people refer to this, somewhat quaintly, as “sun-setting.”

The timeframe for decommissioning depends upon the complexity of replacement applications.

Depending on the applications involved, the actual process of decommissioning can be simple or it can be a complex, multi-year process. For example, if you have a legacy billing system still running and a new one in place, you simply could deal with the data in the legacy system by purging or archiving—and then retire the old system.

If, on the other hand, you’re consolidating legacy systems that are involved in customer communications, the effort likely will be far more complex. It may involve not only application decommissioning, but also new integrations with disparate data sources, forms management applications, print streams and print-output channels. When decommissioning and integration is this complex, people processes—how work gets done—also may need to change.

The order of decommissioning applications:

There is a range of complexity and effort involved in application decommissioning. This makes it difficult to make meaningful generalizations about how to proceed.

Nonetheless, it is possible to make some generalizations about what you’re likely to face as you seek to decommission legacy applications:

  1. Applications that are out of service are the easiest to decommission.
  2. Applications needed only for the data they contain will be relatively easy to decommission.
  3. Applications that are currently in service and support business transactions will be difficult to decommission.
  4. Applications that integrate with other systems will be the most difficult to decommission.

Start with out-of-service or lookup only applications.

Taking these generalities as a starting point, it’s a good practice to begin with out-of-service applications or applications that are used currently only for data lookups. These will be relatively easy to decommission.

Decommissioning these applications generally will deliver significant cost savings because of the reduction in the volume of storage needed and software maintenance costs. This also will reduce your overall information risk surface.

Application decommissioning is complex and depends on the specifics of any given organization. I hope this 6-part blog series has given you a better understanding of the cost- and risk-reduction benefits of application decommissioning, as well as what a high-level framework for tackling decommissioning might look like.

The Doculabs Application Decommissioning Blog Series

Here are the six steps covered in this series:

Step 1: Getting Your Stakeholders on Board

Step 2: Identify and Prioritize Systems to Retire

Step 3: Defining the Archiving Plan

Step 4: Cataloging Data Within the Target Application

Step 5: Archive and Manage the Content

Step 6: Retire Applications

The CISO's Six-Step Guide to Managing Application Risk

Rich Medina
Joe Shepley
I’m VP and Practice Lead, focusing on developing Doculabs’ InfoSec practice and its applications in a wide range of industries.