Mainframe
COBOL to Java, C#
& Cloud
There is no single best approach to mainframe modernization. Depending on the application, an organization may choose to retain, retire, rehost, replatform, replace, rewrite, or translate a COBOL system into Java or C#. Different applications within the same portfolio often require different strategies.
The best choice depends on business objectives, acceptable project risk, the need to preserve existing behaviour, target architecture, available skills, and long-term operating costs.
This guide compares the principal modernization strategies, explains when each is most appropriate, and highlights the advantages and trade-offs of each approach.
The familiar 5 Rs, 6 Rs, and 7 Rs provide useful labels, but terminology varies between vendors. A clearer comparison focuses on what happens to the application, its business logic, and its runtime environment.
| Strategy | Typical objective | Advantages | Limitations | Best suited to |
|---|---|---|---|---|
| Retain | Continue operating without immediate modernization | Lowest short-term disruption and project risk | Platform cost, technical debt, and skills dependency continue | Stable systems with acceptable operating cost and limited change demand |
| Retire | Remove applications or functions that are no longer required | Eliminates modernization and continuing support costs | Hidden dependencies and data-retention obligations must be resolved | Obsolete, duplicated, or genuinely unused systems |
| Rehost | Leave existing hardware, data centre, or hosting environment quickly | Fast migration with minimal application change | COBOL, architecture, and compatibility-runtime dependencies usually remain | Infrastructure exit or short-term hosting change |
| Replatform | Reduce platform dependency while retaining most of the application | Modern infrastructure with less application change than a rewrite | COBOL skills and runtime compatibility may still be required | Applications whose business logic remains valuable and can remain in COBOL |
| Replace | Adopt a package, SaaS service, or industry platform | Uses vendor-maintained standard functionality | Customization, data migration, process change, and product dependency | Commodity business functions supported by established products |
| Rewrite / Rebuild | Create substantially new functionality and architecture | Maximum design freedom | Highest requirements, delivery, scope, and validation risk | Applications whose business processes should be redesigned rather than preserved |
| Deterministic Translation | Preserve proven behaviour while moving to Java or C# | Repeatable conversion, modern source language, and lower functional-change risk | Generated code, runtime libraries, and functional equivalence still require evaluation | Mission-critical applications whose existing behaviour remains valuable |
| AI-Assisted Modernization | Accelerate analysis, documentation, testing, or selected coding tasks | Can improve developer productivity across several strategies | Outputs require governance, traceability, review, and validation | Programmes using AI as a supporting capability rather than an uncontrolled replacement process |
These strategies are not mutually exclusive. A large application portfolio may use every one of them.
The correct strategy depends less on the age of the application than on what the organization wants to preserve, change, or eliminate.
A representative pilot should be used to confirm technical coverage, testing requirements, generated-code quality, runtime dependencies, and likely project effort before committing to a full migration.
AI is best viewed as a capability that supports modernization rather than a modernization strategy in its own right. It can assist application analysis, documentation, code transformation, test generation, and developer productivity across several modernization approaches.
For business-critical applications, AI-generated output should be independently reviewed and validated. Organizations should evaluate repeatability, traceability, security, and functional correctness before relying on AI-generated code.
For a detailed comparison of AI-assisted and deterministic modernization, see:
Large organizations rarely adopt a single modernization strategy across their entire application portfolio. Different systems have different business value, technical characteristics, and modernization priorities.
A typical programme may retire obsolete applications, replace commodity functions, rehost or replatform stable systems, translate mission-critical COBOL into Java or C#, and rewrite applications whose business requirements have fundamentally changed.
The appropriate strategy should be based on application inventory, dependencies, business criticality, testing assets, target architecture, and long-term cost of ownership.
Before selecting a modernization strategy, consider the following questions:
For guidance on project costs, see COBOL Modernization Cost and Total Cost of Ownership . For testing considerations, see Testing and Functional Equivalence of Translated COBOL Applications .
Yes. Most large organizations adopt different strategies for different applications. For example, they may retire obsolete systems, replace commodity functions, rehost stable workloads, and translate or rewrite mission-critical applications.
Rehosting moves an application to new infrastructure with minimal application change. Replatforming also changes parts of the technical environment, such as the database, middleware, operating system, or COBOL runtime.
It is appropriate when an organization wants to preserve proven business behaviour while moving to maintainable Java or C# and reducing long-term dependence on COBOL skills.
A rewrite is appropriate when business processes or application requirements need to change significantly, rather than simply moving the existing application to a new platform.
The choice depends on business objectives, acceptable project risk, desired target architecture, testing capability, long-term operating costs, and whether existing business behaviour should be preserved or redesigned.
A representative pilot is the most reliable way to evaluate translation coverage, generated-code quality, testing requirements, runtime dependencies, and the likely shape of a larger programme.