The Community for Technology Leaders
Green Image
The enemy of all projects is risk: the probability of project failure. Identifying and managing risks is part of the software project-planning process. However, when replacing a legacy system, software professionals often underestimate risk because they assume the legacy system is one of the organization's core competencies and that it represents a set of stable requirements. This perception is true only if the replacement-project development team understands the legacy system and uses it to reduce the risk associated with uncertain requirements. Otherwise, schedules developed under this assumption of design reuse are erroneous. Even if the legacy system's design is reused, it is unlikely that the original methodology and tools will also be reused. In 1989, when I worked at Alcatel-SEL, one of our largest clients came to us with a problem: They were planning a major extension of their transit railway, which was already taxing the limits of their legacy system's host computer. Our initial estimates predicted that the cost of adapting the legacy system to satisfy the client's new requirements was comparable to the cost of replacing the system. We were highly motivated to push for a replacement for other reasons as well: It was becoming very difficult to hire people who were interested in maintaining a 20-year-old assembly-based system, and we had a pent-up dislike of the tedious work the legacy system required. In 1990 the decision was made to replace the legacy system. This article imparts our lessons learned.

W. S. Adolph, "Cash Cow in the Tar Pit: Reengineering a Legacy System," in IEEE Software, vol. 13, no. , pp. 41-47, 1996.
90 ms
(Ver 3.3 (11022016))