In a mainframe modernization project, you will be replacing obsolete or proprietary technologies by mainstream, modern equivalents:

  • a relational database instead of VSAM, IDMS, IMS or Adabas;
  • a modern scripting language instead of JCL;
  • a “distributed” operating system (Linux/ Windows) instead of z/OS, z/VSE, BS2000, Unix;
  • a new programming language to replace your legacy COBOL, Natural, ADS, PL/I ...

While each of the above topics could justify an article on its own, here we will focus on the choice of the target programming language, and more particularly on what will consider the three most popular target languages: COBOL, C# and Java. What should you look out for, and what should be your drivers in choosing one of these?


Cost reduction will always be an important factor in mainframe migration projects. It may even be the only factor, if your application is end-of-life or bound to be replaced or rewritten in a few years. Either way, the choice of the target language can make or break your business case.

The main cost of a language lies in the development environment (compiler, debugger, tools) and the runtime environment. This may vary between “entirely free” (for Java) over “paying development, free runtime” (for C# and some COBOL products) to “paying development and runtime” (for some COBOL products).

However, some less obvious factors may be at play as well:

  • What is the cost and service level of product support? Some cheaper products may offer no or less extensive commercial support, which may be an issue;
  • C# has no runtime cost, but runs only on Windows installations. This is an implicit cost and a potential lock-in that could be taken into consideration;
  • If maintainability is an important factor, have a good look at the development tools available for the language. Especially in the COBOL market space the tool support can vary a great deal.
    Money saved in license cost may result in slower time to market – which comes at a cost too;
  • Some COBOL products are considerably cheaper, but have a performance penalty when compared to more expensive products. This in turn may force you to spend more on the hardware side.

To further complicate things, some COBOL runtimes are licensed per “core” on the target infrastructure. And although we can provide rather good sizing estimates for replacement infrastructure upfront, these figures always need to be validated in actual performance tests.
So it may be hard to get an exact list-price for these products until after a real-life performance test.

On the positive side: thanks to our conversion and testing tools, it is easy to change to a different target COBOL dialect, even during the project.

Leaving behind the cost aspects, let’s look at some other aspects that may influence the selection of a target programming language, in no particular order.


The impending shortage of qualified staff is one of the most frequently heard reasons for migrating off the mainframe. This is not just a concern for development staff – it is just as problematic for legacy database administrators and system operators. For the staffing of your development team however, your options will depend largely on the choice of target programming language. It should ideally:

a) allow easy re-training of current development staff so application expertise isn’t lost;
b) have a sufficiently large “user base” so skilled new developers are easily found;
c) have a sufficiently large market share so support is guaranteed in the foreseeable future.

When it comes to language popularity, Java is topping the various popularity charts for years on end . C# is – depending on the source – anywhere between first or fifth runner-up, however because of its technical similarity to Java, we consider it to be naturally second place. You’ll have no trouble finding experienced new developers for both languages. Question is however whether your existing (“legacy”) developers are eager to learn such a new language.

On the other hand, choosing COBOL as target language is not an obvious choice either. Your existing developers may prefer it, but finding young COBOL developers may be a challenge. The 1950’s language is not particularly “sexy”. In a 2013 survey by Micro Focus , 73% of 119 polled universities didn't offer COBOL programming classes and only 18% had COBOL as part of their core curriculum. That being said, COBOL isn’t a difficult language to learn – anyone with basic IT knowledge and motivation could take it up quickly.

Still, if staff shortage is a current issue for you, migrating towards COBOL would seem to be a missed opportunity – or a temporary solution at best.

Strategic fit

Today’s enterprises rarely run on mainframe only. Often distributed systems are already in place, for instance to take care of front-end presentation, web, mobile…

In such cases it makes sense to align the migration target with the existing distributed environment (typically consisting of either .NET or Java). Obvious benefits are a single strategic platform and the re-use of existing expertise, infrastructure, and development teams.

Again, if you already use COBOL on distributed systems it makes sense to convert the mainframe application to COBOL as well. In most other cases however, the trend seems to be to convert towards Object Oriented alternatives. A 2012 survey showed that only one third of the interviewed companies was happy with their COBOL applications. One third was actively moving away from COBOL and another third would like to move away but found it too expensive or difficult.

A pragmatic third option could be to convert your mainframe applications to so-called “managed COBOL”, which is COBOL running on top of a Java or .NET Virtual Machine. Once running there, the converted application can more easily integrate with new or existing development in native Java/C#, or be gradually rewritten to those languages, thanks to the shared underlying VM.

Readability and maintainability of the converted code

Readability of a COBOL-to-COBOL conversion is not really an issue as there is not much of conversion happening. When converting towards C# and Java things are different though.

Arguably, when converting a legacy application to an OO language, the best readability can be achieved by a complete manual redesign and subsequent rewrite, a so-called “green-field” approach. This is rarely an acceptable option due to cost and timing constraints. But even then: it would require an in-depth understanding of every aspect of the application, which is simply not realistic given the sheer size and complexity of most legacy applications.

The alternative is to go for a technical approach where each statement or each construct is converted individually, without requiring an understanding of the larger context. This kind of conversion is something that can be automated by specialized software tools, they will be able to convert large amounts of code quickly, consistently and as often as required, regardless of the business area of the application.

In our opinion, this kind of technical tool-based conversion is the only way that any multi-million lines-of-code application can be efficiently converted within reasonable budget, timing and risk constraints.

And in order to minimize the effort and the risk for human error, the tool’s first concern should be a fully automated conversion and guaranteed correct target code. Readability should -and can- be maximized within those constraints, not the other way around.

C# vs Java – differences and similarities

C# and Java are both powerful and flexible languages, and generally do a good job replacing legacy source languages as diverse as COBOL, Natural, ADS, PL/I, and even Assembler to some extent. But they are rarely a perfect fit. So what are some of the challenges when converting towards C# or Java, and are their solutions to these challenges any different?

One major challenge for both C# and Java is the concept of “copybooks” (sometimes also known as “include files”). Copybooks are a form of code re-use, and as such contribute a lot to the readability of legacy languages. The problem is that copybooks are basically just snippets of “text”, not “code”. They don’t have any formal “meaning” on their own. Only in the larger context of the insertion point a copybook receives an unambiguous meaning and can be processed or converted correctly. The same copybook can receive a subtly different meaning (and thus a different conversion result) at different insertion points. As a result, it can be quite challenging to replace copybooks with a functionally equivalent OO alternative. In some extreme cases the only option may be to “expand” the copybook in the various locations where it is used.

Another example where any OO language faces the same problem is with special legacy types like packed decimal, zoned decimal. These cannot be ported directly to native types in the target language, as they exhibit different side effects such as subtly different overflow, rounding… It is essential that all legacy behavior is exactly reproduced in the target, so often specific classes are implemented in C# or Java that represent these legacy types. The business code would then use these types (PackedDecimal and ZonedDecimal for instance) instead of decimal (in C#) or BigDecimal (in Java).

While generally very similar, there are also a few differences between C# and Java. A nice feature only available in C# is Operator Overloading: you can define the meaning of for instance the plus (+) operator on any object type. This is particularly useful in combination with the previously mentioned “legacy types”. The C# code can continue to use the normal plus operator to add a ZonedDecimal with a PackedDecimal for instance. This makes converted mathematical expressions much more similar to the original code. In Java, this needs to be solved differently.

So while there are some technical differences between C# and Java, we would say they are roughly equivalent as target language, and your choice may be impacted more by one of the other criteria discussed earlier (notably cost or strategic fit).

Finally, more important than the technical properties of the target language, is how they are being used by the conversion tool. The creativity and the effort that a vendor has spent in designing a solution can result in entirely different solutions, even for the same target language. Hence our advice: do a thorough market study before deciding.


There are many aspects to consider when choosing the target programming language for a legacy conversion. There is no “right” choice, and much depends on your main drivers. Risk and complexity are reduced by staying with the same language (e.g. COBOL-to-COBOL). In the long term however, and especially if staffing is an issue, conversion to an object oriented language should be considered.