Mainframe
COBOL to Java, C#
& Cloud
COBOL application modernization options are often categorized into 5 or 7 R's: Refactor/Rewrite, Rehost/Re-platform, Re-purchase, Retire, and Retain.
The benefits range from higher costs but better long-term ROI associated with invasive approaches, to lower cost and shorter lifespan associated with relatively quick lift-and-shift approaches.
While Rehost/Re-platform has been popular over the past few years, re-implementation in an up-to-date language is gaining 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 its functionality. In the world of legacy modernization, the process is also associated with changing the architecture and language of the application and is frequently associated with moving the application to the cloud - with or without changing the language.
The primary benefit of this approach is when the application's language is changed from COBOL to a modern language. It is important to note that the value of business applications lies in their functionality and not in the way the functionality was expressed in COBOL. The language does not matter; it is not a piece of Shakespearean 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 a manual rewrite. Using an automatic translator, they successfully migrated their COBOL to Java.
Automatic translation may also have its 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 the COBOL code. The changes typically may involve changing 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 the least invasive option, and has the highest short-term benefit. It reduces immediate running costs and requires minimal changes to the code.
However, the new system will still require testing. Typical owners of business-critical applications - banks, insurance companies, and governments are unlikely to switch from the mainframe to the same system running on another machine without a certain level of testing. Sometimes a spot testing strategy suffices, but one way or another, detailed test suites and test data need to be prepared. Many organizations have already made this move, and hopefully, many have already retained some of their test scripts and data ready for the next step of Refactor/Rewrite.
In most cases, when an off-the-shelf replacement has been available, the legacy application has already been replaced. What remains is tailor-made for the organizations and cannot be shoehorned into an Off-The-Shelf product.
The issue 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. Determining what is needed and what can be retired may prove to be more complicated than it first appears.
Looking strictly at the COBOL codebase rather than the platform it runs on (cloud or mainframe), if/when the application could have been replaced by an off-the-shelf product, retired, or Re-platformed/rehosted - it would have been. Hence, the remaining COBOL codebase is tailor-made to a specific requirement and cannot be easily retired or replaced. And yet, the value is in the functions they provide, and in the business logic, not tied to the COBOL language. Which brings us back to Refactor/Rewrite.
© 2023 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.