Maintaining Legacy Software

Do you have a legacy application that is too expensive to maintain?
What can we do about that and how can we help?

There is no easy answer because generally costs are high and the required resource to replace code is large. But sometimes it is easier to be given choices from which an informed decision can be made.

There are four basic overall strategies:-

• Bite the bullet. The in-house development staff takes on the task of building the entire replacement system. Because the legacy application is probably large, it will require the development staff to essentially concentrate on this development for several years until it is done.
• Parallel development. Employ contract developers to build the new system in-house while the existing development staff continue to support the legacy system. The three main problems with this approach are:-
  a. The original development staff are not going accept the role of maintaining the legacy system.
  b. What to do with the extra staff once the new system is completed?
  and
  c. Double the cost of development staff until the new system is completed.
• Piecemeal replacement The in-house development staff replaces the worst offending modules of the legacy system one-at-a-time by developing a new module that replaces the corresponding module in the legacy system. In theory the legacy system is eventually entirely replaced. One problem is that such systems never seem to get done also it takes too long to integrate the new module. The new module is likely to have in built problems that it inherits from the original application and it doesn't take long for the project to become unmanageable.
• Outsource the replacement. Lets us develop the new system so that all the in-house development staff have to do is worry about the transition from the old system to the new system.