Out With the Old: Tips from an 'Application Assassin'

In with the new and out with the old….

In with the new! One of the most appealing aspects of working in technology is the continuous change that brings the latest languages, vendor capabilities, and design patterns into focus. This change frequency means something new is always capturing the imagination, headlines, and budget. Here! Here! … In with the new! But what about “out with the old”? One of the hardest aspects of working in technology is to finally turn something off. Rarely does that new initiative completely obviate the need for an existing application, as a result, the world of technology is full of applications living far past their expiration date, unloved but somehow still surviving. I suggest that in 2024, to the great benefit of our careers and organizations, we all can become more deliberate and celebratory about executing on “out with the old” and completely shutting off old applications.

At a recent holiday get-together, a client executive excitedly talked through his five-year plan to truly exit their core banking system, moving to a cloud solution heavily utilizing APIs that span both solutions in making the transition. Upon reflection, shutting applications down has not typically been the stuff that rapid career advancement is based on, but this gentleman will be wildly employable in five years! I was suitably impressed with their long-term planning; but to be successful at the process of shutting down, thinking about the topic across four vectors is useful: ownership, understanding, planning, and acknowledgment.

Ownership

As the leader, aligning ownership is the first step; if you are a contributor, it’s a great way to get a feather in your cap to ask to ‘own’ an unloved feature, function, or application and work out how to deprecate it. If you’ve ever found yourself learning a company’s infrastructure, you start with a placemat concept – “I should be able to describe this on one, albeit complicated, A4 size page, right?”. You quickly realize that as you look closer and closer, more and more applications surround what was described as a straightforward situation. It is very rare in practice for a technology landscape or product portfolio, when put under overall scrutiny, to have direct ownership established across every application/capability, instead much of it is shared in a gray/shared area or unowned.

Making the case/understanding

Whether you are a leader or contributor, gaining a deeper understanding of the true costs of ownership helps make the case for action. In a previous role as a product management head at a large software provider, I found that significantly underappreciated security costs existed whether a product had zero or hundreds of installed clients. Beyond this, there were fulfillment, product, and legal support costs with a fixed threshold regardless of client base. This insight made me an ally of the security organization, making it easy to push to close out subscale ‘failed experiment’ solutions, where previously finding the time to go through close-down never would have occurred. While you may not work for a software vendor, you likely have a similar fixed overhead per application coming from your security audits. It can be real money and time saved. Over dinner, a senior banking technology executive friend recently shared that it costs them @$100,000 per year per application to conduct security audits.

Planning

Shutting down requires a plan to execute. Getting the new volume off the solution is one thing, but what about archival? How far out do you need to communicate the intent to shut down? I have led the end-of-life (EOL) of a long-standing antiquated profitability and cost management solution. As a good partner, we announced the EOL along with extended support periods with plenty of advance notice (a three-year horizon until extended support began); it took two years for some clients to even respond with their intentions. This response led to these stages: “End-of-life,” “Post-end-of-life,” “really-final-post end-of-life,” and then finally, “It’s not a contractual thing; no one works here anymore that can help you.”

At CC Pace, we engage with our clients across all manner of activities, but one of our consultants, Sheila Clemens, specializes in this sort of work. Sheila has had the pleasure of shutting down twenty enterprise applications throughout her career, earning the “Application Assassin” nickname. Sheila is a Minnesotan through and through and was nice enough to provide these twenty execution considerations to help you be more successful in your “out with the old” resolution:

1. Business Owners must communicate with end users of the application to inform them it will be decommissioned and plan accordingly with archiving information and the transition to the new application (if needed).
2. Establish a decommission plan or playbook to track all tasks. This task may be a team effort based on the Business Owner’s and customer base’s feedback.
3. Archival of data needed for legal requirements and/or user access for historical information and ensure users have means to access in the correct format if required.
4. Decommission lower environment servers, including databases before PROD servers.
5. Business Owners and Technology Product Owners should confirm that no end users of the application are still connecting, using the application, etc. by either removing access or shutting down application services/servers for X days before moving on with decommission tasks.
6. Remove any automation jobs that import data for the decommissioned application.
7. Remove any interfaces, external communications, file transfers, e-mail distributions, etc. associated with the application to be decommissioned are removed from service.
8. Remove backups. Remove monitoring.
9. Software client removals from workstations. Software removal/archival from software library, etc.
10. Decommission application Active Directory service accounts. Remove service accounts from any password management/storage tools (CyberArk, etc.).
11. Decommission application Active Directory Security Groups. Remove all users from groups for X days before decommissioning the groups.
12. Remove firewall rules for the decommissioned application. Decommission SSL certificates.
13. Decommission Lead to work with Procurement/Vendor Management to terminate vendor support and maintenance, infrastructure, software operating systems, or major software applications and supporting software applications. This may also include vendor-provided contractor termination for support of the applications.
14. Security Vulnerability remediation with the decommission of end-of-life infrastructure and applications. Working with Information Security departments to close any open findings.
15. Remediate any Policy Exceptions in place due to outdated infrastructure and unsupported applications.
16. Remove user manuals, knowledge articles, architecture diagrams, and other documentation for the decommissioned application. Update disaster recovery plans/retire plans.
17. Update Configuration Management System (SNOW, HPSM, etc.) to remove any support queues, playbooks, and update software/hardware configuration items, etc.
18. Decommission VM’s or workstations that were used to access old applications, for instance, running old browsers or older versions of desktop software to access.
19. Remove any Global browser settings, IE Compatibility Mode, etc., for application URLs in Edge.
20. Remove any physical hardware in data centers, etc. Ship any vendor-owned hardware or appliances back to the vendor. While we do not recommend throwing the AS400 into a local lake, this rumored Minnesotan ritual certainly ensures that the job is truly complete.

Acknowledgment

Finally, acknowledge and celebrate shut-downs the way you celebrate go-lives. Send an email to the team and supporting cast with a headstone thanking the old application for its service.

Make it known that you care about the successful retirement of the old applications in your organization and the benefits to be gained!

To paraphrase Michael Porter, the essence of (technology) strategy is deciding what you are not going to do (any longer). There’s no time like the present! And if you think you could use the support of an “Application Assassin” to get the job done, we are at your service!