SIDEBAR: Living with Your Legacy System
LEGACY SYSTEMS can be like ticking time bombs. Even if a business case can be made to replace them, doing so takes time. If you have to live with a legacy system for a period of time before replacing it, you should take these steps to protect your business:
- Conduct performance tests and capacity planning at least once a year.
- Test critical applications thoroughly, especially buffer overflows that can lead to application failure.
- Develop workable backup plans to deal with catastrophic legacy system failures.
- If you find that the legacy system has so much value to the business that replacement is not an option, create a business case plan for legacy system modernization, whereby you reduce the risk associated with it.
- You no longer have anyone on staff who understands the language that it's written in.
- You can't locate the source code or documentation, and the only person who understands the design retired years ago.
- There is no one around who can fix the application on short notice.
- Backup systems haven't been tested for years, or they're manual and too hard to implement even if you wanted to.
- The original vendor went out of business.
- You're not sure how many more transactions the application is handling than it did when you last upgraded it.
- You discover there are other applications wired into the system that you weren't aware of.
- Your company is still highly dependent on the system for everyday operations.
SIDEBAR:Your Legacy System May Be Too Big a Risk to Tolerate When . . .
Although the legacy system that failed Comair was 18 years old, age by itself is not an indicator that a legacy system should be replaced, says Robert Charette, director of the Cutter Consortium's enterprise risk management and governance practice. There are other, more relevant facts - in addition to its maturity - that may make your legacy system intolerably risky, such as: