Mainframe COBOL to Java, C# & Cloud

Comparison of COBOL Migration Strategies

COBOL migration options is often stated as 5 or 7 R's :Refactor/Rewrite, Rehost/Replatform, Re-purchase, Retire, Retain. The benefits range higher cost associated with invasive approaches with long ROI, to lower cost approaches with shorter lifespan and shorter ROI.


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 funtionality and not the beautul way the functionality in 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 it 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 require testing : Imagine this: the owner’s of business critical applications (banks, insurance, government ) are unlikely to switch to from mainframe to same system running on another machine without certain level of testing. Sometimes this takes the form of spot testing – but one way or another, they will need to prepare test suits and test data. 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 –'refactor' .


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 you only need a small part of the application, but 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.


Strickly looking the COBOL code base rather than the platform it runs on (cloud or mainframe) when it could be replaced by off-the-self product, retired or replatform/rehosted to cut the running costs – it would have. 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 funtions they provide, and the in the business-logic, not tied to COBOL lanaguage. Only if there was a tried and tested way of moving the COBOL code to new modern languages.

  © 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.