The core system of Visma Aquila, a provider of payroll and HR solutions for the public sector, had been built on COBOL since the early 1990s. COBOL was a reliable and widely used technology at the time, but over the decades its development has become labor-intensive.

Visma Aquila launched an extensive conversion project three years ago to convert the COBOL system to the more commonly used Java language. Technology company twoday, which provides data and AI solutions as well as software development, was invited to participate in this interesting case. twoday and Reflector have a long history of collaboration and approached this client need together as well. From Reflector, Seme Hokynar and Vesa Saarinen participated.

Why is there urgency in companies to modernize COBOL systems?

COBOL systems have been an important or even critical part of business operations in many companies for decades. However, as technology has evolved and diversified, their development has become slow. COBOL no longer adapts easily to current requirements, and the experts who handle COBOL are retiring one after another.

The situation is complicated by the scope and layered nature of the various systems used in companies: over the years, companies inevitably accumulate vast amounts of code and systems that have been implemented at different times, in different computing languages, with different approaches, and with different partners.

How to Start a COBOL conversion in a controlled fashion

twoday and Reflector entered the Visma Aquila project without precise visibility into the numerous details of the system. The challenge was business logic containing over a million lines of code. There was also no certainty about what would happen to the business rules if the programming language was changed to Java.

In the early stages of the project, COBOL code was converted manually. However, it became evident that such a massive entity could not be handled without automation: for a single developer, the conversion would have taken decades to accomplish.

The project proceeded by building a Proof of Concept solution (POC) to determine whether the conversion was even possible. The POC focused particularly on the client’s own domain-specific programming language (DSL), which was based on COBOL technology. The POC demonstrated that the work was feasible if done in stages.

Automation brought momentum to the COBOL conversion

Next, the project proceeded by developing a tool that produced Java code from COBOL code. The first versions were not perfect, but they provided a clear framework that could be further developed. Through automation, the style of the code was standardized, which was essential in managing such a large entity.

Many structural differences between COBOL and Java were identified in the conversion work. For example, COBOL’s level-88 variables can represent Boolean values, Enum-type structures, or even Pattern Matching logic. None of these have direct equivalent in Java.

Today, this customized conversion tool produces nearly perfect code that the client’s own developers can utilize going forward. COBOL code is now run through the tool and development continues in Java platform, which was also the original objective of the work.

How to create a maintainable Java solution based on COBOL?

The migrated Java code is the foundation for further development. It must be easily understandable and maintainable. Essential to the design of Visma Aquila’s conversion tool was producing code that an experienced developer could write even themselves: not only technically functional, but also logical and high-quality code.

Many automated conversion tools on the market produce code that is extremely difficult to maintain in practice. Fully automated conversion can produce code that is technically correct, but confusing in practice. Therefore, the tool must contain intelligence and the conversion must always be studied from a developer’s perspective. The actual development work begins after the completed conversion.

Additionally, for error resolution purposes, the code structure should initially resemble the original COBOL code—this way, error situations can be located more efficiently in the future.

Managing system modernization risks with vertical components

One of the key lessons from the project has been dividing the conversion work into vertical components: complete set of functionalities are converted and deployed to production one at a time. In this way, problems are surfaced and resolved in time, rather than converting the entire system first and then attempting to fully deploy it only at the end.

This approach not only reduces risks but also delivers visible results to the business faster.

The impact of runtime environment on COBOL–Java conversion

The conversion project is not just about the code. The runtime models of COBOL and Java differ significantly. COBOL environments often run separate processes for each task, whereas Java applications operate on a continuously running JVM (Java Virtual Machine) utilizing internal threads for concurrent execution.

The client’s technical organization also gets to learn new things. If Java is already in use elsewhere in the organization, the learning curve is smoother. However, a completely new environment requires proper familiarization and investments in capability increase.

The whole is sometimes almost an archaeological project

Conversion projects often surface much more than just COBOL code: shell scripts, configuration files, database triggers, and other logic. These cannot be ignored, as they affect the system’s operation and code interoperability.

Therefore, conversion is always also about managing environmental change and often an archaeological project where structures forgotten over the years are brought to light.

Risks of legacy systems if modernization is delayed

If companies’ old systems are not updated, their maintenance becomes impossible. New requirements cannot be implemented and business agility disappears. License fees for old systems can skyrocket. Developers become frustrated with old environments and end-user experience deteriorates.

Modern development models enable faster response, better support for business, and lower risks. It is not just about technology.

What was learned in practice from the COBOL conversion project?

twoday and Vesa Saarinen from Reflector have been involved in the Visma Aquila and twoday project from the beginning. In three years, countless challenges have been encountered, most of which are not technical but relate to documentation, testing, and the lack of tacit knowledge.

One of the most important lessons has been understanding that without specifications and test cases, the work becomes slow error resolution. Test cases are essential: if they do not exist, they must be built. Without test cases, the conversion cannot succeed in a controlled fashion.

Another key risk is the loss of expertise and know-how. If the last remaining experts leave the organization before knowledge has been documented and test cases built, development becomes practically impossible.