Why should you modernize legacy software?

Victor Klaren, Thinkwise CVO: I regularly come up against the following: companies that are still running their most important business applications on an IBM AS/400 server. They would be delighted to get rid of it, but do not know how. Most of the time the software still works fine and they are afraid of the risks, uncertainty, and costs of re-developing everything from scratch. Let us explore the added value and implications of carrying out such a modernization process.

The most important reason to replace legacy software, is that something is no longer working correctly or is missing. This is not the case with many legacy applications. If the software is technically outdated, but still satisfies all the functional requirements, then there is little reason to modernize it from that perspective. Legacy software can also become functionally obsolete, making it unable to perform more modern tasks. Consider, for example, populating a webshop or an analytics platform. In this case, companies tend to choose to build a modern peripheral application on top of the legacy application, rather than modernize the legacy application itself.

And who can blame them. IT projects involving your primary business application are complex, expensive and risky, and have a direct impact on your business operations. The safest option is therefore to settle for the current functionality of your legacy application and postpone its modernization indefinitely. But what if there is a possibility to retain the existing functionality and at the same time modernize the technology?

Different ways to modernize

In general, there are three ways to modernize a legacy application, each with its own advantages and disadvantages.

1. Conversion of the source code
Firstly, you can try to convert the old programming language to a new programming language. But you then quickly run up against several problems. The concepts applied within various languages are often very different. For example, how do you switch from a procedural to an object-oriented model? Or from an RPG application on an AS/400 to a 3-tier application? Or from a character-oriented user interface to a mobile variant?

The philosophy of your old application is quite often lost during this conversion process. In addition, the conversion software makes several assumptions, which can seriously increase the number of bugs in the new application. The combination of the above issues makes the new software extremely difficult to maintain.

2. Use a GUI front-end (wrapping)
A solution that is often chosen is to leave the code as it is, and develop a modern user interface on top of the legacy application. This appears to resolve the problem, at least from the outside, but the downside is that every time you change your core process you have to modify both the legacy application and the front-end application. This further inhibits the continued development of the application.

This technique is only an option with very stable legacy products where there is no need to react to changes in their environment. A permanent disadvantage is that the core application, which still uses the outdated programming language, still has to be maintained. It is questionable whether developers with knowledge of this old language are still available and for how long. At some time in the future these developers will retire, and the legacy software will have to retire with them.

3. Derive a software model
A new emerging technology is to use a low-code platform for core systems. Some platforms offer the option to derive a low-code model from the legacy software, so that you can define the crucial philosophy of your core application. During this process, the core functionality of the application is specified, including the data models, GUI structures, processes, and translations. In fact, everything that is available on a meta level. The derived model is usually not complete; this differs for each technology and application. But it is evident that this provides a considerable jump start for a modernization project. In practice you can derive 20 to 50 percent of the functionality, and that is a tremendous saving for large applications.

Continued development after modernization

With every type of legacy modernization, you have to look beyond the initial project. You will want to continue to develop the application. This is the most difficult aspect with conversion, because after the conversion the original philosophy of the application no longer exists. With ‘wrapping’ the problem remains that you have to apply every modification twice, and you will also have to find and hire expensive developers who are still able to work with the obsolete technology.

On the other hand, a low-code model offers excellent possibilities to easily continue development. It is even possible to automatically enrich the models based on smart analyses of the metadata. This not only speeds up the further development, but also provides a uniform process.

Avoid new legacy software

The replacement of legacy software is considered to be an important and growing problem for the future. Gartner dedicated an entire conference to this topic at the end of 2018. As time passes, the maintenance costs of legacy software continue to increase. And ultimately, of course, there will be a time when the technology can no longer be supported.

An even bigger problem, and one that you almost never hear about, is that right this minute many organizations are still creating the legacy of the future. Nowadays, it is becoming increasingly easier to implement new software, but no one knows how long this software will remain popular and whether it will be technically supported. This has become a more or less accepted problem.

The only way to avoid the creation of new legacy, is by modernizing your business applications with a low-code platform for core systems that is capable of automatically switching to a different technology. If you continue to develop with such a platform, it is guaranteed that the technology on which the software runs will always be kept up to date and that no new legacy will ever be created. In other words: a definitive solution for the legacy problem.