Can the Modernization of Your Legacy System Be Automated?

They still exist — legacy systems developed in Cobol, PL/1, Smalltalk, or other once-modern programming languages that hardly anyone learns or wants to program today. Old, large software systems that grow increasingly complex over the years, while knowledge of them and of the languages and technologies they use continues to decline. Over time, the pressure to modernize such legacy systems grows ever greater, until management finally decides to release the necessary funds and launch migration projects. But when does automated modernization of your legacy system actually make sense?

It is often not sensible to develop a completely new system. Enormous numbers of business decisions are deeply embedded in the program code. Documentation? Nowhere to be found! Adequate test coverage? Of course not. Migration projects are also long-runners, and during a migration, the system being migrated is constantly evolving.

And where should the migration lead? Will Java still be relevant in 10 years? More than 10 years ago, it was claimed that Java was the new Cobol. That is not yet the case, but other programming languages, architectural approaches, and frameworks are competing for the favor of software developers. This is also reflected in the job market. If legacy systems still need to be maintained, it is difficult to find developers who can or want to do it. And if they can, they charge a premium for it.

Technology Changes Faster Than Business Logic

So it remains: Large parts of legacy systems are simply kept running and maintained to death. Attempts are made to attach or build new systems onto them, naturally using the latest technological standards. Today, microservices are often extracted from a monolithic legacy system, providing functionally separable parts as independent small services and being internally redeveloped at this or a later opportunity.

This cannot be achieved with the entire system. Because within it lies a great deal of business logic, the truth of which is contained solely in the code. The business logic is current — only the technology is old. And after a migration, it will eventually become outdated again.

In migrations, the typical approach is to supplement the incomplete documentation with the equally incomplete knowledge of the (former) participants and to complete it with insights from the code. From the result, the requirements for the new system are created and implemented. Naturally, this approach does not capture the actual requirements fully or implement them correctly. Furthermore, different people will typically implement the new system than the old one. The latter are still occupied with maintaining the legacy system, do not have sufficient mastery of the new target architecture and technology stack, or are no longer with the company.

How can this dilemma be solved?

Legacy System — The Truth Is in the Code

To overcome these gaps, the only source of truth should be used: the program code. It contains at any point in time the absolute truth about the productive legacy system. Why is this fact not exploited?

Of course, it is not quite that simple. Legacy systems are developed in different programming languages, the interaction patterns can differ significantly (e.g., host compared to web applications), or parts of the program logic cannot be meaningfully transferred to a new target architecture. The level of abstraction in program code is zero. And machines cannot automatically abstract. This is like making sausage (program) from pork (requirements) and wanting to reverse the process. Proponents of reverse engineering approaches may propagate such things, but I have yet to encounter projects where this has been achieved with justifiable effort to a sufficient degree.

Nevertheless, parts of the truth can be abstracted from program code and other sources of the system. For example, every screen-based system has a series of screens that are identifiable and whose structure can be read from the code. Some concepts are recurring, for example the UI widgets used and their arrangement (layout) on the screens. What applies to application screens can also be transferred to other structures of the application: domain structures, processes, decisions.

The schematic portion of program code is quite high in typical enterprise applications. Much of the code revolves around what information is presented to users and how it is processed (often: persisted) in the backend. If only this information could be extracted and automatically transferred to a new system, a great deal would already be gained.

Does Partially Automated Migration of Legacy Systems Work?

Well, unfortunately one cannot expect miracles here. Every system is different. What information can be extracted from legacy systems and how varies every time. The target architecture is also always individual.

For example, the legacy system could be an Oracle Forms-based solution, and the target a typical modern stack with Spring Boot in the backend and React on the frontend. From Oracle Forms applications, for example, metadata of the Forms application can be exported to XML. This contains information about screens, fields, data binding, validation, and much more. Using the extracted data, the same functions can be created in a different technology stack.

For the mapping, transformation tools are needed that are capable of reading and processing the source data and transferring it to a target system. This is typically done by generating source code for the target system. These transformation tools must be developed individually.

However, the source data also contains a great deal of information that is very specific to the legacy system and is difficult or impossible to transfer. In the case of Oracle Forms, for example, the behavior of UI widgets is described by PL/SQL code. While much of this is again schematic, certain procedures are highly individual. For this, a parser must be implemented that recognizes the PL/SQL code and maps it into usable target code. Neither is trivial.

Is It Worth Developing Individual Transformation Tools?

That cannot be answered in general terms, except with: it depends. First, it must be investigated what information from a legacy system can be extracted and how. If no suitable tools exist, they must be created. How much effort this requires depends on what sources can be accessed in what way. The above-mentioned XML export has proven itself well, for example. Sometimes only the pure source code remains — and then it becomes all the more laborious.

The extracted data must be transferred to a machine-readable format that contains all relevant information to generate the skeleton of a target application. Typically, a reference implementation for the target architecture is created manually. This is structured in such a way that the information gained from the extracted structural data can be transferred to schematic code. This schematic code is separated from the code that cannot be derived from the source data. This is referred to as the Generation Gap Pattern.

Once this is achieved, generator templates can be derived from it. The generator must also be individually programmed. Programming languages that directly support code templates as a feature are well-suited for this purpose, for example Xtend.

You can then gradually extract further information from the legacy application and convert it into schematic code by means of generation. Often, however, there is a limit up to which this automatic transformation makes sense. Once the effort to create the transformation tools exceeds that of manually transferring and verifying the transferred functions, manual reimplementation of those parts should be preferred.

However, there are always parts for which the effort to create the necessary transformation tools is less than the manual reimplementation effort. Additionally, the transformation-based approach ensures that the schematically generated parts are always implemented homogeneously and exhibit higher quality than manual code. Because if there is an error in the transformation templates, it can be corrected centrally and, after re-running the generator, is fixed at all affected locations in the target code.

Who Is Partially Automated Migration of Legacy Systems Suitable For?

There is no universal answer to this either. We have worked with companies from various industries and supported them in their migration projects. Admittedly, not every legacy system is suitable for migration according to our approach. We have found that the potential can be uncovered within a few workshop days together with those responsible for the legacy system. On this basis, it can then be decided whether implementing a proof-of-concept prototype is worthwhile. Based on this, it can then be assessed whether the path should be pursued consistently or not.

Legacy Modernization at itemis — We analyze the potential of your legacy system together with you and support you on the path to a modern architecture: Legacy Modernization →