Migrating from COBOL to Java or C#: Three Critical Success Criteria

In 2020, Astadia experienced a seven-fold increase in the amount of inquires received from prospective mainframe customers who were evaluating options to modernize and migrate their legacy applications. After talking to hundreds of mainframe customers last year, three critical themes were common in nearly every conversation:

• Executives want to modernize their mainframe before the staff that supports the mainframe retires.

• The opportunity to achieve significant cost savings was too compelling to not pursue.

• The pandemic accelerated their digital transformation journey, and their mainframe applications may not be suited to meet their current needs and future goals.  

To solve these widely experienced challenges, an automated refactoring of COBOL to Java or C# is emerging as one of the top paths forward for many organizations. At Astadia, we take a consultant first approach with our customers, understanding that there is not a “one size fits all” solution for everyone. It is important to work alongside our clients to understand their goals and objectives to be able to recommend the best path forward that meets the needs of both IT and the business.

For some clients, an automated refactoring of their COBOL applications to Java or C# is that best path forward. This is often pursued by clients who are having challenges finding COBOL developers. In addition, the high and often rising maintenance and run time fees for COBOL products offer the opportunity for customers to pursue significant cost savings. Lastly, we often encounter clients who are experiencing a lack of application extensibility and interoperability with non-COBOL applications.

The Astadia COBOL to Java or C# conversion toolset offers clients a pragmatic, cost effective, and 100% automated approach to convert COBOL into Java or C#, along with the leading relational databases. The toolset is defined by three critical success criteria:

1. Customization and Consistency

Anyone who has written software in a team before knows that any program can be written in a variety of ways. A professional software conversion tool will provide the means to apply customization options that suit the requirements of the customer. These options can be simple things like naming conventions and the formatting of comments, or they can be more sophisticated, like the extent to which the tool will optimize structural patterns in the COBOL code.

At the same time, the tool should make it possible to manage a configuration of customization options for a consistent application in an iterative process. These management facilities should also include configuration of other aspects of the migration like the translation of scripts, screens, or databases.

2. Maintainability by COBOL and Java or C# Developers

Consistent translation improves the maintainability of the generated Java or C#, but for the Java/C# code to be easy to work with for the original COBOL developers, it also needs to be based around simple design principles. This means the tool should generate code that allows, as much as possible, a 1:1 relationship between the number of lines of COBOL code and the number of lines of Java/C#, and reuse (wherever it is syntactically allowed) the names of identifiers appearing in code. This will facilitate the recognition of business entities and rules in Java/C# by the COBOL developer.

At the same time, Java/C# developers with limited exposure to COBOL should be able to pick up the programs and be optimally productive in the shortest possible timeframe. Simple design principles improve the understandability of the converted programs also by Java developers. Typical COBOL constructs that are unknown in Java or C# (like DECLARATIVES or PERFORM) are transformed into their closest Java/C#-style equivalents.

3. Functional Equivalence with COBOL and Full Support for the Target Platform

The basic requirement of a conversion tool is that the code it produces is 100% functionally equivalent (including side effects encountered at runtime) with the original COBOL code. At the same time, the code that is produced should enable full use of the richness of the target Java or .NET platform.

This means some COBOL language syntax will be replaced with calls to .NET APIs or Java SE and EE platform APIs. It also means that the code should be fully usable in modern development tools like Visual Studio, Eclipse, IntelliJ or NetBeans and support execution in debug mode. Last but not least, the converted programs must easily be integrated with newly written Java or C# (and to a wider extent: .NET) programs and vice versa, hereby ensuring a solid basis for continuous improvement and further modernization.

How can a client determine if migrating from COBOL to Java or COBOL to .NET is the best path for their organization?

We encourage those considering a migration project to reach out and ask about our Rapid Questionnaire process. The Rapid Questionnaire is a free, and relatively low-effort process that asks to share details such as your mix of technologies, number of programs, and lines of code. It typically requires our customers to invest 1-hour of their time to complete and allows us to build a high-level roadmap of what a mainframe migration journey will entail, including estimates for both the timeline and cost. To get started, please fill out this form.

Additional Resources

For further reading, our COBOL to Java and COBOL to C# white papers are available for download:

> Transforming COBOL to Java

> Transforming COBOL to C#

‍