The Effective CIO

Retiring Legacy Applications – Logically January 17, 2012

A recent article on eliminating legacy applications prompted a bit of back-and-forth on Twitter, centered around why we all do such a bad job of retiring old systems.  Such a conversation requires more than a few tweets, however.  Why is it so hard to kill off old systems?

We all have no problem listing the theoretical reasons why an application should be retired:

• It no longer meets the users’ needs
• It becomes too costly to maintain
• Better technology is readily available
• Integration with other, newer applications is getting more difficult

Yet we all have applications that no longer meet user needs, are too costly too maintain, could be replaced with better technology, and barely integrate with our other systems. Why is it so hard to kill off old applications?

One word: metrics. Very few CIOs develop, collect, manage, and analyze the metrics to prove that an application is past its prime.  Without hard data to document usability issues, cost concerns, or replacement expense, retiring an application shifts from being a matter of fact to a matter of opinion.  When opinions start driving the discussion, it becomes almost impossible to kill off anything in IT.

While some things can be difficult to fully measure (what is “better technology?”) other things can be easily tracked to drive retirement decisions.  In particular, usability metrics can give great insight into how users use a system, which features matter, and which features can be abandoned.

The right time to think about retiring an application is the day you begin to develop or acquire it. If you engineer usability metrics into a system, that data will be invaluable in five years when you may need to pull the plug.

Imagine a system with a few thousand reports. Imagine being tasked with eliminating the unnecessary reports. Imagine doing that with no empirical data. Imagine having to instead rely on user conjecture and anecdotal data on which reports are the “important ones.”  Users are notoriously inaccurate in deciding these things; perception and reality are very different animals.

I once had to retire an old mainframe system which several users insisted they used on a regular basis.  We saw no evidence of this, but they were adamant. Finally, we simply locked their userids to see what would happen.

The result? No complaints. It turns out they were using a completely different system that they thought was the mainframe. When we pointed this out, they happily allowed us to proceed with the retirement.

A bit of usage history would have been quite helpful. But no one ever instrumented the system to track such things, so we were left with drastic measures to move forward.

The next time you build a system, instrument the code to record who does what when.  Disk is cheap; collect the data and see what users are actually doing in your applications.  During the life of the application, such data will help tune the app and allow you to focus on what users really need.  As the app approaches its “golden years,” you’ll know when usage drops to the point that you can safely pull the plug.  As always, a little planning now saves a lot of pain and heartache later.

[tweetmeme source=”EffectiveCIO” alias=”http://j.mp/CIO001″ only_single=false]