Mainframe
COBOL to Java, C#
& Cloud
When it comes to modernizing mainframe applications written in COBOL, experts commonly discuss various approaches, often referred to as the 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 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 mainframe 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 as COBOL code. In this context, the language of the source code, be it COBOL, is not what's important; it is not a piece of Shakespearean work.
The pivotal question in refactoring or rewriting is whether to opt for automatic translation systems like SoftwareMining's, which aim to produce maintainable code, or to undertake a manual rewrite of the application. It's worth noting that manual rewrites for larger applications carry significant risks from the failure to accurately extract existing business rules to the potential for scope creep. It's telling that we've had clients approach us only after experiencing the pitfalls of a failed manual rewrite. By opting for an automatic translator, they were able to successfully migrate their COBOL applications 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.
We have successfully resolved these common challenges by executing multiple COBOL translation projects. Explore our migration success stories to learn more.
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.
Even with a new system, testing is essential. Banks, insurance companies, and governments, who often rely on mainframe-based business-critical applications, won't switch to a different system without thorough 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 the majority of instances, when an off-the-shelf replacement for a legacy mainframe application is available, the transition has likely already been made. The remaining applications are usually highly customized to meet specific organizational needs, making them unsuitable for standard off-the-shelf solutions.
Enterprise application suites from vendors like SAP do offer customization options that can be tailored to an organization's unique requirements. However, such customizations often result in vendor lock-in and entail additional expenses for implementation and maintenance.
The challenges of retiring mainframe applications are multifaceted. One common issue is underestimating the need for certain application components until their absence creates a problem. Additionally, what may initially appear as a modular and expendable part of the application could turn out to have essential dependencies within the larger system. Accurate determination of which elements are vital and which can be safely phased out can be more complicated than initially anticipated. If specific components prove irreplaceable or are not suited for off-the-shelf solutions, enterprises are faced with two choices: either continue with the existing mainframe and its associated operational costs or consider alternative strategies such as rewriting or rehosting the mainframe application.
When evaluating the COBOL codebase independently of the hosting environment, be it a cloud or mainframe, it becomes evident that if a transition to off-the-shelf products, retirement, or re-platforming/rehosting were feasible options, they would have already been executed. The applications that remain are highly specialized and fulfill specific organizational requirements, making them irreplaceable or unretirable in the short term. Nonetheless, the core value of these applications lies in the business functions and logic they provide, not in their COBOL origins. This leads us back to considering more transformative strategies such as Refactor/Rewrite.
© 2024 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.
