IT Leadership // CIO Insights & Innovation
09:06 AM
Connect Directly

Legacy IT Systems: Hidden Risks Revealed

Don't keep legacy systems around. They introduce hidden risk to your organization. Jonathan Feldman, CIO for the City of Asheville, N.C., offers firsthand advice on how to land that plane before it crashes.

Where 2016 US Presidential Contenders Stand On Tech Issues
Where 2016 US Presidential Contenders Stand On Tech Issues
(Click image for larger view and slideshow.)

Legacy systems that won't die. You know you've got one. But do you realize you are harming your organization by suffering to let it live?

I should know, I've done it. Following are my suggestions for safely landing your legacy IT plane before it crashes.

There are two kinds of legacy systems: production systems that should be legacy, and systems that are no longer in use that are used for "lookup only." There's a gigantic difference between the two. The first kind has its own problems that have been adequately documented elsewhere. The case boils down to this: Your organization is trying to be a 21st century enterprise, yet it's using 20-year-old technology. 

I've inherited such an organization in the past, and I sympathize with any CIO who does. The organization hasn't invested in tech, executives are fairly ignorant of the impact, and the CIO must do a whole lot of education. In these scenarios, stakeholders don't know what they don't know, yet there's a pervasive feeling of discontent among them all.

You can't blame them. Their child's swim-team app has a higher level of technological sophistication than their own workplace apps do. The new CIO must take decisive action that is generally supported by the executive management team.

[There's something rotten in the state of IT. See Why It's Time to Say Goodbye to IT.]

Yet, I will submit to you that this is a less dangerous scenario than the more common legacy situation, in which outdated systems are allowed to stick around for lookup purposes.

I am guilty as charged. I allowed such a system to linger for years before I finally took action.

What's the Risk?

Generally, keeping a legacy app around for lookups is considered to be mostly harmless.

It is not, and here's why: Users and IT have different assumptions. Often, your end-user assumes that if IT is keeping a legacy system around, you're keeping it around in a fully functional mode. Users assume backups are being done, redundant systems are still redundant, and vendor support is still available if something goes wrong.

Operating a mainframe, circa 1960.
(Image: HultonArchive/iStockphoto)

Operating a mainframe, circa 1960.

(Image: HultonArchive/iStockphoto)

IT, on the other hand, assumes that business users have already migrated over all important data, and that they will be using the legacy system only for the sake of convenience.

Both parties are wrong in their assumptions.

Regarding the end-user assumption that IT has everything covered and will keep it running perfectly, let me assure you that once users are migrated, the IT posture towards the system changes. IT staff thinks, "The system is no longer in production, so why should we invest?"

There may be hard budget reality behind this. If you're swapping an ERP, you budget for one maintenance cost, not two. Maybe a secondary system costs more, so you dump it because, "The system's only for lookup. If it dies, nobody will care."

The IT posture around a system that is perceived to be no longer needed is to keep it on life support. Maintenance is generally dropped. "We'll keep it around until it dies. No resources are needed."

There you have a fatal IT assumption: Nobody will miss the system if it disappears.

In fact, most of the time, someone will miss the system. Then, you're spending resources on responding, repairing, and even rebuilding.

When a system is allowed to stick around for lookup only, what that really means is that users of the system don't feel any sense of urgency to drop it. 

This posture starts with the data conversion process. Because many longtime employees will be comfortable with the old system, they'll use the old lookup-only system to look up data that is perhaps vital to the enterprise.

Thus, they won't have those "aha" moments after the new system goes live. They're not using the new system to look up old data, and therefore they will not realize when something that should have been converted was not converted.

That means that your new system potentially has gaps in the data sets that were brought over, which then means that vital data has one copy -- on the old system.

This happens more often than you'd think. Data Q/A Q/C is all well and good for data sets that get converted, but the pragmatic way to ensure that the right data sets get brought over to the new system is to prevent people from using the old system.

Let that sink in. If you allow access to the old system, it means that vital data might be overlooked in the conversion.

Even if you accept the risk that vital data might be overlooked, keeping a legacy system around means that vital processes might start depending on that legacy system. Maybe new employees will be trained to use the old system to look something up during a sales process or another critical procedure.

Whether you're risking data, process interruption, or both, the risk to your organization is this: catastrophic failure instead of planned unavailability.

Planned Obsolescence Instead

So, what's the answer? Make it clear to your IT customers during the new system selection that the old system will be decommissioned. Set expectations that the new system's backups, resiliency, and maintenance mean that the old system won't have those things, so it's in the IT customer's best interests to exit the old system. 

If you didn't set the expectation at the time of the new system launch, it's not too late to have the conversation. Approach it from the customer's self-interest, and present it to him or her in terms he or she will understand.

"There's an engine on fire and we're landing!" is one way to get the message across. When I did this, I got some pushback--but I wasn't dogmatic about it. I was fine with a deadline extension, so long as there was a deadline in the foreseeable future. Also, in my case, once we made the old system unavailable, it did indeed turn out that there was a data set missing in the new system.

We often talk about risk and security hand-in-hand, as if security is the only thing that introduces risk into the organization. But legacy systems, when they stick around past their expiration date, can become a hidden risk requiring serious mitigation and action.

Does your company offer the most rewarding place to work in IT? Do you know of an organization that stands out from the pack when it comes to how IT workers are treated? Make your voice heard. Submit your entry now for InformationWeek's People's Choice Award. Full details and a submission form can be found here.

Jonathan Feldman is Chief Information Officer for the City of Asheville, North Carolina, where his business background and work as an InformationWeek columnist have helped him to innovate in government through better practices in business technology, process, and human ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
2/27/2016 | 1:51:26 AM
Re: 20 Year Old technology
@TerryB: I think he was just speculating. It is true that C family is a rather strong family and it is able to do anything. But creating AI with already available resources is really tough. We need a new system just for AI.
User Rank: Ninja
2/26/2016 | 12:38:20 PM
Re: 20 Year Old technology
@yalanand, where did you see this C retirement info? That is language that i5 has compiler for, I never saw where IBM planned to retire it? I could see them stopping to enhance the compiler anymore by adding new features but can't believe IBM would hang companies out to dry who have applications written in C?

Great example though. I still use RPG on i5, which has origins back to 1960's. But the RPG today, especially the free format version, looks nothing like it did. It looks like modern language now. I use it for my server side, take AJAX calls from Extjs clients. I much prefer that over server scripting languages like PHP or using raw SQL from client side, much more secure calling compiled RPG programs. You don't buffer overflow the i5, get your code to run and then modify the o/s. As character on Living Color used to say "Homey don't play that!".  :-)

Even the i5 o/s itself can hardly be labeled legacy, still the finest business o/s ever written (with apologies to MVS). They got to RISC 64 bit a decade ahead of Windows and without any of the pain. Would I implement Facebook or Natl Weather service on i5, heck no. Wrong tool for job. But any transaction based business not dealing with unstructered data, still the best and most secure server in the world.
User Rank: Ninja
2/26/2016 | 1:57:44 AM
Re: 20 Year Old technology
I agree. Legacy can be diversified. If you mean old hardware and implementation technology then these need changing, but the underlying code base, say C, why should I change that, since it has more than 15 years left before retirement. Old OS shouldn't be kept because of security and they are tedious and often cannot manage VLDS (Very Large Database Systems) efficiently.
User Rank: Ninja
2/25/2016 | 12:58:00 PM
20 Year Old technology
I'm struggling to understand what you are trying to say. If someone running hardware/os that hasn't been touched in 20 years, I'd agree that might be a problem.

I run a rack mounted IBM POWER6 server running i5os, an operating system originally invented in 1988. If you are saying it is legacy because it was created 20+ years ago, you are way off base. Last I looked a car was created about 100 years ago now, we all driving legacy machines these days?

You are in the public sector. I hope to God you are spending your tax dollars on what makes sense to get the job done the most effectively and efficiently, not because of what you think is cool/cutting edge technology.
The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends to Watch in Financial Services
IT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on for the week of October 9, 2016. We'll be talking with the editors and correspondents who brought you the top stories of the week to get the "story behind the story."
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Flash Poll