Mainframe COBOL to Java, C# & Cloud

Mainframe modernization approaches: The 5 Rs

COBOL migration options are often stated as 5 or 7 R's: Refactor/Rewrite, Rehost/Re-platform, Re-purchase, Retire and Retain.
The benefits range from higher costs and but better long term ROI associated with invasive approaches, to lower cost and shorter lifespan associated with relatively quick lift-and-shift approaches.

Whilst Rehost/Re-platform has been the popular over the past few years, re-implementation in an up to date language is gaining a lot of momentum due to advantages offered by embracing Java and C#.

In this paper we attempt to outline the major benefits and issues with each of the approaches:


In development circles, refactoring is the process of restructuring existing code without changing functionality. In legacy Modernization world, the process is also associated changing architecture and language of the application and is frequently associated with moving application to cloud - with or without changing the language.

The approaches primary benefit is when the application's language is changed from COBOL to a modern language. Bear in mind the value of the business applications it's functionality and not the beautiful way the functionality was expressed in COBOL. the language does not matter, not shakespearean pieces of work.
The main refactoring question is whether to use automatic translation systems such as SoftwareMining's, or to manually rewrite the application.
Manual rewrite of bigger applications can be very risky; from failing to extract some of the business-rules to scope creeps. We have clients who came to us only after a failed attempt at manual rewrite. Using automatic translator they successfully migrate their COBOL to Java.
Automatic translation may also have its own concerns: from heavy use of legacy architectures (from GO TO statements to POINTERS), to performance See 16 Features needed in Successful Translation of COBOL Applications.
Through numerous projects we hope to have resolved most of these by now. Read our migration success stories.


These approaches involve minimal changes to COBOL code. The changes typically may involve change of data sources, such as moving from VSAM or IMS to SQL / relational databases, or optimizing the modules for cloud deployment,
With minimum changes to the COBOL codebase, this is by far least invasive option, and has highest short term benefit. It reduces immediate running costs, requires minimal changes to code.
But the new system will still require testing. Typical owners of business critical applications - banks, insurance, and government are unlikely to switch from mainframe to same system running on another machine without certain level of testing. Sometimes a spot testing strategy suffices, but one way or another detailed test suits and test data needs to be prepared. Many organizations have already done this move, and hopefully many already have retained some of their test scripts and data ready for the next step of Refactor/Rewrite.


In most cases, when off-the-shelf replacement has been available, the legacy application it has already been replaced. What remains, is tailor made to the organizations and cannot be shoe-horned into an Off-The-Shelf pro.


The issues with retiring is - you don't think you need it until you need it. Or assuming only a small part of the application is needed, but then discovering it has dependencies on the larger application. Determination of what is needed and what can be retired may prove to be more complicated than it first appears.


Strictly looking the COBOL code base rather than the platform it runs on (cloud or mainframe), if/when the application could have been replaced by off-the-self product, retired or Re-platform/rehosted - it would have. Hence, the remaining COBOL code base is tailor made to a specific requirement and cannot be retire or replace easily. And yet, the value is the functions they provide, and in the business-logic, not tied to COBOL language. Which bring us back to Refactor/Rewrite.

  © 2022 SoftwareMining is a trademark of Software Modernization Technologies Ltd (UK). Registered in England company no: 07300248. Reg Offices: 79 Stevens House, Jerome Place, Kingston Upon Thames, KT1 1HX, United Kingdom.