Netscape, according to Joel Spolsky in his famous essay Things You Should Never Do, made “…the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.” The wisdom of rewriting legacy systems was a lively topic of debate when Spolsky published his opinions in 2000, and it’s still a topic that inspires arguments now. Is it something you should never do?
The three approaches discussed here are: (1) Rewriting, (2) Replacement or (3) Reuse
The problems with rewriting your legacy system
Rewriting may seem like a good idea because your customers are demanding more than your legacy system can provide in its current format, however, the only potential justification for rewriting is if the costs of maintaining the application have become greater than the costs of rewriting the application, or, if developers are hard to find, then, and only then, would it be time to even remotely consider such a drastic change.
But sometimes a rewrite can’t be avoided
Unless absolutely necessary, however, rewriting should be avoided, since this approach is contrary to one of the fundamental rules of business - an organization should put its money and effort into things that directly benefit the customer.
Another way out of the legacy dilemma is replacement
Another alternative is to replace pieces of a legacy system by buying a package solution. Customizing a package can be very complex, but in some situations it may be the best choice. Like rewriting, it’s risky, and like rewriting it should be considered only when the legacy system is becoming literally impossible to maintain because of the unavailability of staff or hardware issues.
External providers can be quite a good choice for keeping a legacy system healthy but it is a choice that requires significant commitment too. Integration needs to be addressed, data may need to be migrated, and security is sometimes an issue. Outsourcing offers similar advantages and drawbacks.
Reuse is the best way forward
Reuse is the best solution for modernization. With the reuse approach you can continue to leverage your valuable legacy system with minimal training and enhanced application workflow. Compared to rewriting, reuse takes less time, it’s safer, and it’s cheaper.
Reuse allows you to update small pieces of a system at a time, and test each small change. Small successful changes make the entire system more understandable and easier to work with, and, a carefully applied system of frequent updates helps to keep the entire system healthy. Reuse can, inch-by-inch, make the entire system fit better with new technologies and applications without breaking the bank.
So, with these three approaches to consider, what will your company do?