What to Do About Those Legacy Systems

By Jodi Mardesich

The word 'legacy' usually has a positive connotation -- something handed down from an ancestor or predecessor, such as property or a family trait.  In the world of IT, however, legacy systems are viewed as problematic relics of the past -- old mainframes, minicomputers, or outdated applications built with programming languages no longer taught and rarely used. And the situation is exacerbated as programmers who know how to work with legacy systems are retiring.

Legacy systems and legacy thinking are the biggest challenges to transforming business today, according to the Gartner Group. While legacy systems pose a challenge for the public and private sector alike, government organizations are increasingly looking to replace processes with less costly, off-the-shelf solutions. At the federal level, the President's Management Agenda has called for streamlining processes, putting more government services online and integrating different government computer systems so that information can be shared. But government CIOs face an uphill battle because even purported "one-size-fits-all" solutions to legacy application woes can cost millions of dollars.

Despite being old and outdated, legacy systems still work, providing critical functions such as accounting and payroll. As long as they're still working, some CIOs may be tempted to leave them alone. But experts advise examining the true cost of allowing legacy systems to continue operating.

First, they are expensive to maintain. "Companies spend 80% of their software budgets on ongoing operations and maintenance, leaving just 20% for new investments," says Phil Murphy, principal analyst with Forrester Research. "That is not enough funding for projects that can increase revenue and leverage new business opportunities."

Legacy applications cost so much to maintain due to the lack of knowledge about them, Murphy says. 

In addition, legacy applications may not scale to meet the needs of a growing company. And because they were built before federal and state compliance standards like Sarbanes Oxley and HIPAA were created, they may be compliance risks, as well.

What to do with legacy systems

Murphy says there are four possible outcomes facing CIOs with legacy systems:

1. Leave them alone CIOs don't have to rip out or change legacy applications. "Not every application needs fundamental changes," Murphy says.  "Few firms can afford to change every application. Ask why an application should be changed, rather than why it shouldn't be changed. Since IT budgets are limited, focus on the applications that need the most attention."

2. Modernize them If leaving applications alone is not a viable solution, public sector CIOs can try to make the case that the failure of a legacy system could jeopardize important government programs. If changes are necessary, there are several options, from simple interface fixes to changing platforms and languages, Murphy says. Some options include creating Web-to host interfaces; breaking down components of the applications and re-working them with new tools; migrating to new operating system platforms or database systems; and migrating to new programming languages.

3. Replace them CIOs who opt to replace legacy systems can go several different routes. They can rewrite the application; purchase a packaged application; purchase a hosted application; or acquire an open source version of the application. This can be done in-house or it can be outsourced.

4. Retire them Even if retiring the application is the best option, shutting legacy systems down doesn't come without a price tag.  "There may be considerable effort to unhook an application from all the places it touches in a mature organization to ensure that those touch points are replaced or plugged and that nothing is broken," Murphy says.

Making the case for your choice

There is no one solution that meets the needs of every situation, Murphy says. Each option has its merits. But there is one thing every CIO should do: start with an inventory, and use automated application portfolio management (APM) tools to find out what they have, and go from there. "IT managers have been evaluating applications based on insufficient information for years," Murphy explains.

APM tools in essence take an inventory, enabling CIOs to find out what is happening in IT and take corrective action. "You can't design the future state unless you know what the current state is," Murphy says. "The right way forward for everybody is to rationalize the applications, to build metrics around them so they know what they have, and know what value they are to us and know whether or not the applications are worth modernization." For example, find out if an application supports three people in the mailroom, or if it supports the core work of 500 people, Murphy says.

Legacy applications aren't all decades old. New legacy applications are being created every 18 months, Murphy says. Applications written in Java and Perl and C++ become legacy when the original authors move on.

"There is no blueprint left behind," says Murphy. "Folks that go in to fix them have to recreate the wheel. It's a fairly widespread problem."

By getting a handle on what IT assets exist, and creating a plan to deal with legacy systems, both past and future, government CIOs can be progressive, moving from disconnected, stove-piped systems and toward a future of government systems working together.

Jodi Mardesich writes about business and technology. Her writing has appeared in The New York Times, Fortune, San Jose Mercury News, Salon, Slate, and Yoga Journal.