Legacy IT Systems: Hidden Risks Revealed

Where 2016 US Presidential Contenders Stand On Tech Issues

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.

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.