Pile of legacy software looking to be fixed or replaced

Legacy Software: Fix or Replace?

When legacy software gets too old, support eventually becomes life support. It reaches the point where the only choices are massively revising the existing code or starting over fresh. Neither alternative is pleasant, but sinking endless effort into revisions is a recipe for failure. When developers’ best efforts aren’t working, you need to step back and decide whether a complete replacement is necessary.

Assessing the Legacy Software Code Base

The decision isn’t an easy one. Developers will always grumble about how bad the old code is. Documentation is never as good as they’d like, and any large body of code has parts which are very hard to figure out. But certain signs indicate that the revision will require unreasonable amounts of effort and still offer no guarantee of success.

  • Lack of progress. Progress may be slow, but if it comes to a standstill for an extended period, that bodes badly. You need to know whether the stagnation is real or only apparent. The developers may be reworking low-level functions to make everything better, and their work might have no visible effect till it’s done. The problem arises when they keep trying different ways to fix broken code, and nothing works.
  • Failure in the planning stages. If the developers can’t formulate a viable course of action, they won’t get anywhere. The problem may be organizational rather than technical. It may be because the technical problems run so deep that every plan to attack them leads into insurmountable issues. If it’s the latter, serious measures are necessary.
  • Repair by piling on kludges. When the only way to maintain the code is by making it even harder to maintain, that’s a dead end. Piling on glue code and mixing programming languages don’t just postpone the problem; it makes it worse.

Signs of Major Trouble

There are several signs that suggest a code base is most likely unsalvageable. One may not mean much in itself, but when multiple signs are present, keeping it working will be painful at best.

  • Obsolete technology. A project written in a programming language which is rarely used today is hard to maintain. If it requires an antiquated development environment, that makes the problem even worse.
  • Lack of documentation. No project has ideal documentation, but if it’s seriously lacking or full of errors, then developers have to reverse-engineer the code to understand and fix it. It’s possible to do this if the code is clean enough, but it often isn’t.
  • One-person support. The situation where only one person understood the code is all too common. When that person leaves, the others have to scramble to make sense of it, and they may not be able to.
  • A weak base. Perhaps the software wasn’t that good in the first place. If it’s always been plagued by maintenance problems, it isn’t going to get better.

Making the Replacement Successful

Insurmountable problems with the legacy software don’t guarantee that a replacement will succeed. If anything, they make it harder. The new application has to fix the problems of the old one and not lose any necessary functionality. Figuring out how to do that is hard when it’s not clear exactly what the old code did.

A systematic approach is necessary. The first step is to determine the users’ current requirements. Some features of the old software may no longer be necessary. Figuring out how to migrate the data is one of the big challenges.

The revision needs to start with a requirements document, which all stakeholders will review. The next step is a design document and a review for it. When the new application is ready, it should be deployed alongside the old one if possible. That will identify any areas where it doesn’t meet the requirements and let people keep working while it’s revised. Only after the new application meets everyone’s satisfaction is it time to retire the old one.