There is no single right answer for modernizing COBOL. Here is what the realistic paths actually look like, and what matters most when choosing between them.
The code itself is rarely the hard part. COBOL programs are usually well-structured and the business logic is explicit; the real cost is in the surrounding ecosystem, JCL, VSAM/DB2 access patterns, CICS transactions, and decades of undocumented operational knowledge about when and why things run. Automated conversion tools have gotten materially faster: Blu Age has publicly documented converting 12 million lines of COBOL to Java for an insurance client in roughly six months. That kind of timeline is realistic for well-isolated batch systems, not for a tightly coupled online transaction system with heavy CICS dependencies.
Keep the code, modernize around it
Vendors taking this approach for COBOL: Rocket Software, Micro Focus (OpenText), ARCAD Software, OpenLegacy.
Rewrite or convert to a new platform
Vendors taking this approach for COBOL: AWS Mainframe Modernization (Blu Age), Astadia, TSRI, CloudFrame, Accenture, Capgemini, Ispirer, Semantic Designs.
Keep it running, don't change it yet
Vendors taking this approach for COBOL: IBM.
Fill the workforce gap without a migration project
Vendors taking this approach for COBOL: TCS / Infosys.