The Care and Feeding of Legacy Systems
Show of hands: How many remember Y2K? Those of us who lived through it can never completely forget the sheer terror of not really knowing whether elevators would stall between the 87th and 8th floors or planes would fall from the sky at midnight on December 31, 1999.
Why was this event so frightening? The answer is that most legacy systems are, at least to some degree, proverbial "black boxes." Systems that are developed over long periods of time lose any straightforward characteristics and become more and more spaghetti-like with each workaround. They are poorly documented, and the people who originally built them have probably long since moved on. We just don't know what's going on inside these systems—yet, there they are, working pretty well and keeping the business humming along.
Legacy systems can be tremendously frustrating. Users have requested changes that seem small—a longer or smarter data field, a simple dropdown list—only to be told the change will take months to implement, or cannot be accomplished at all. IT management may have approached the organization's executives to ask about reengineering the system to achieve gains in functionality or performance. Outside vendors offer turnkey systems to replace legacy systems, but the costs are enormous—and turnkey systems can rarely perform all the functions needed to support your organization's very specific needs. Vendors are reluctant to modify their systems, as the modifications will need to be performed again and again with each software update.
As tempting as it is to contemplate a shiny new system, there are sizeable risks involved in starting over. The unique functionality inherent in your organization's legacy system is a critical part of your organization's "intellectual capital," if you will. Attempts to change or rebuild the system can be labor-intensive for both IT and line managers, and these projects rarely are delivered on time or within budget. Even with the best efforts and intentions, these projects often cause broad-based, unanticipated "collateral damage," possibly even loss of critical functionality and/or data—and then it will be all hands on deck to try to rebuild the system. In short, legacy system replacement projects are often a lose-lose proposition for both IT and the business at large. Even if the project goes according to plan, there will be a material investment in requirements documentation, user acceptance testing, new operational practices and training.
But what if you need additional functionality that just isn't there? When undertaking custom development projects, every effort should be made to build around existing systems. It is often more cost-effective to "black box" legacy systems from further development, and implement enabling technologies which surround the legacy environment and draw from its resources where needed.
Should you make the decision to go ahead with legacy system replacement, the legacy system should be firmly cordoned off and allowed to operate normally while the new system is prepared and tested. We suggest running the old and new systems in parallel for at least a full year. Only when the new system is proven to be fully operational, completely capable of delivering all the functionality required and able to withstand all the vicissitudes of the organization's daily business needs should the legacy system be taken offline. The risks are just too high to handle such a project any other way.