IT GovernanceLegacy Support

Legacy Systems: Replace Them or Hold Them Dear?

There reaches a point in business where legacy systems become load-bearing walls. If you extract them, it gets everybody extremely nervous about what may or may not collapse. How do you know when to pull the trigger and invest in a new solution anyway? In an article for Project Times, Rahul Ajani discusses the elements you should consider.

The Age of Change

With legitimately legacy systems, it is not uncommon for them to be “black-boxes” where few people really understand how they work, and documentation may be difficult to find. But when supported by middleware and virtualization, legacy systems can admittedly continue doing quite a bit. For the sake of business continuity and not disrupting internal or external customers, leaving the legacy system as is always feels like a viable option. The alternative is extremely costly restructuring and training programs to introduce a new system and prepare workers to use it.

There are, of course, some good reasons to consider that alternative, in spite of the cost:

  • Slow systems based on aging architecture or technology stifle innovation.
  • Business needs have outgrown the current system, which was likely not designed to scale.
  • Legacy systems were not built with modern security threats in mind.
  • The effort involved to customize legacy systems to communicate with new systems is increasing.
  • Nothing lasts forever, especially technology.

All the same, “if it ain’t broke, don’t fix it,” became a phrase because it is a viable strategy, with New Coke being the popular example. There needs to be a legitimate business case beyond “I’m tired of this old stuff” to upgrade technology. Ajani cites the following as the situations when you can say affirmatively that it is time to upgrade:

  • When the system stops evolving
  • When the system starts decaying
  • When there is abundant technical debt

When the zeal to support and maintain a technology starts to dwindle a bit, that is the first large sign that a system is losing its relevance. Ajani goes on to say this:

Over the years a legacy system will gain a lot of orphaned, duplicate, redundant, and less than optimal source-code. You may wonder ‘why?’ Better ask HR department how many developers, analysts, and architects came and went. Better yet ask IT department what were standards of documentation back then. The legacy systems invariably grow fat with broken architecture in it, popularly known as ‘software rot.’ This is the point of no return. Unfortunately, from here any action (or inaction) to improve the system will lead to disasters.

Of course, what it ultimately boils down to is that you upgrade once the benefits outweigh the costs. The tricky part is proving that, so search high and low for useful data. You can view the original article here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.