SoftwareMining •
COBOL to Java & C#
• Predictable & Repeatable
Selecting a COBOL-to-Java or COBOL-to-C# conversion vendor requires more than comparing generated source code. Organisations should also assess conversion completeness, functional-equivalence testing, data security, deployment flexibility, code ownership, runtime dependencies and evidence from comparable production projects.
The right supplier should be able to explain how the complete application will be analysed, converted, tested and supported. This guide outlines the main differences between conversion companies and tools, and the questions enterprise buyers should ask before selecting an approach.
COBOL modernization suppliers do not all provide the same service. Some supply conversion tools for use by the customer or its systems integrator. Others provide a consultancy-led migration service, while some propose a manual rewrite or an AI-assisted redevelopment project.
This distinction affects project control, security, repeatability, cost and long-term dependence on the supplier. A tools-based approach can allow the customer to run conversion and analysis within its own infrastructure. A service-led approach may require source code and application information to be transferred to the supplier.
Before comparing vendors, determine whether the organisation wants to own and operate the conversion process, engage a supplier to deliver the entire project, or use a systems integrator supported by specialist conversion technology. See our comparison of COBOL modernization strategies .
Ask each vendor whether its approach is rule-based, AI-assisted, manually developed or a combination of these methods. The answer should make clear how consistently the same COBOL construct is converted and whether the conversion can be repeated after source-code changes.
A demonstration based on a small program is useful, but it does not prove that a complete application can be converted. The evaluation should include representative business logic, data definitions, files, database access, online transactions, batch processing and error-handling paths.
Vendor demonstrations and benchmark results should be supported by evidence from representative enterprise applications. Buyers should establish how much of the supplied source was converted, whether the generated application compiled and executed, which platform dependencies were supported and how much manual correction was required.
Recent assessments of AI-based COBOL conversion also show why vendor claims should be examined carefully. See Gartner's assessment of generative AI-based COBOL conversion and SoftwareMining's technical evaluation of Claude Code for COBOL conversion . Both raise important questions about completeness, platform coverage, repeatability and the testing required before enterprise deployment.
COBOL syntax is only one part of a production application. Vendors should identify all supported and unsupported technologies before the project is priced or scheduled. Depending on the source environment, this may include:
The supplier should also explain how unsupported statements are reported. Silent omission is substantially more difficult to detect than a clear conversion warning or exception.
Generated source code should be complete, readable and maintainable using standard Java or C# development environments. Ask whether the output uses pure JDK or .NET facilities, which runtime libraries are required, and whether ordinary developers can debug, extend and deploy the application.
Code appearance alone is not sufficient. The evaluation should establish whether COBOL data semantics, numeric behaviour, file processing, control flow and transaction handling are preserved. Buyers should also confirm that they receive the generated source code and have the right to modify it independently of the vendor.
The most important measure of a conversion is whether the new application produces the same business results as the original. Vendors should describe how converted programs are compared with the COBOL system, how test data is managed, and how differences are traced and corrected.
Testing should cover normal processing, boundary conditions, negative values, error paths, database updates, reports, files and online transactions. For large applications, automated comparison of outputs and database changes is normally more dependable than relying only on manual inspection. Read more about functional-equivalence testing for COBOL conversion .
Enterprise COBOL applications often contain confidential business rules and references to sensitive data. Establish where the source code will be processed, who can access it, whether it is retained, and whether it may be submitted to third-party or public AI services.
Running analysis and conversion within the customer's own infrastructure can reduce the need to transfer source code or test data outside the organisation. If the supplier performs the work externally, its security, confidentiality, data-retention and subcontracting arrangements should be reviewed before code is supplied.
Keep conversion under your control. SoftwareMining's tools can run within your own infrastructure, without transferring application source code or test data to SoftwareMining.
Confirm where the converted application can run and which components remain dependent on the conversion supplier. The target should support the organisation's chosen deployment model, whether on premises, on Linux or Windows, in containers, or on cloud platforms such as AWS and Azure.
Ask which runtime libraries are required, how they are licensed and supported, and whether fees increase with transaction volumes, processors or deployment instances. Source-code ownership does not by itself eliminate dependence on proprietary runtime components.
A useful price comparison should include more than the initial conversion charge. Consider tool licences, professional services, runtime fees, infrastructure, testing, remediation, training and ongoing support. Establish whether the price is fixed, based on lines of code, or dependent on the duration and staffing of the project.
Buyers should also confirm who owns the generated code, whether conversion can be repeated without further charges, how product updates are supplied, and what support is available after deployment. Review SoftwareMining's COBOL-to-Java conversion pricing and our broader COBOL modernization cost comparison .
Ask for projects that resemble the proposed application in size, platform and transaction profile. A successful batch conversion does not by itself demonstrate support for a large CICS or IMS application. Useful evidence includes the converted scope, target environment, testing performed, production date and the length of time the application has operated.
SoftwareMining's published examples include the conversion of ING Bank's 1.5 million-line CICS, COBOL, DB2 and JCL application to Java. The converted application entered production on Linux in February 2022. Other projects include Bank of Montreal, TransUnion and a US State tax application. See our COBOL-to-Java conversion case studies .
Evaluate SoftwareMining using your own representative code. Download the tool for use within your environment, or ask SoftwareMining to convert a sample for review.
A proof of concept should test the supplier's method rather than only produce attractive sample code. Include programs and artefacts that reflect the difficult parts of the application, then assess:
An evaluation performed within the customer's environment provides direct access to the tools, reports and generated source. If this is not practical, a representative sample conversion can still help establish technical coverage before a larger commitment is made.
SoftwareMining provides established, rule-based COBOL-to-Java and COBOL-to-C# conversion tools for enterprise customers and systems integrators. The tools can operate within customer infrastructure, allowing organisations to retain control of their source code, application data, testing and deployment process.
Customers own the generated Java or C# source code, and SoftwareMining does not charge runtime licence fees. Supporting runtime libraries, product updates and optional application support are available for converted applications. The generated systems can be deployed on premises or to environments including AWS, Azure and Kubernetes.
Organisations can download and evaluate the SoftwareMining conversion tool within their own environment, or arrange for SoftwareMining to convert representative sample code.
Before selecting a COBOL conversion company or tool, obtain clear answers to the following questions: