Mainframe Modernisation: Rewrite, Refactor or Replatform

Mainframe modernisation is rarely a single decision. It is a choice between several distinct strategies, each with a very different cost, timeline, and risk profile, and the right answer depends on your business goals rather than on technology preference. Choosing “rewrite everything” when a replatform would do, or “lift and shift” when the real problem is unmaintainable code, is how modernisation programmes waste millions.

This guide compares the main modernisation strategies, when each makes sense, and how to choose.

TL;DR

• The main strategies are rehost, replatform, refactor, rearchitect/rewrite, replace, and retire; most are commonly grouped as rehost, replatform, and refactor/rewrite
• Rehosting is fastest and cheapest but changes the least; rewriting delivers the most modern result at the highest cost and risk
• The right choice depends on business drivers: cost reduction, agility, risk, skills availability, and the state of the existing code
• Most large UK programmes blend strategies across the estate rather than applying one approach to everything

Why Modernise the Mainframe at All

The drivers are consistent across UK enterprises: the COBOL and mainframe skills pool is retiring, mainframe operating costs are high, the systems are hard to change quickly, and integrating them with modern cloud, data, and AI platforms is difficult. Doing nothing carries its own growing risk as expertise disappears. The question is usually not whether to modernise, but how.

The Mainframe Modernisation Strategies

Industry frameworks list six or seven options; in practice they cluster into a few meaningful choices.

Rehost (“Lift and Shift”)

Move the existing application, largely unchanged, onto new infrastructure, for example emulating the mainframe environment on cloud or commodity hardware. The COBOL code stays broadly as-is.

• Pros: Fastest and lowest-cost option; low delivery risk; immediate escape from mainframe hardware and licensing costs.
• Cons: Changes almost nothing about the code. You still have COBOL, still have the skills problem, and gain little agility. It is a cost play, not a modernisation of the software itself.
• Best for: Organisations that need to exit mainframe hardware quickly and defer deeper modernisation.

Replatform

Move to a new platform with some adjustments, for example recompiling COBOL to run on Linux or in the cloud, or moving the database from DB2 to a modern equivalent, without rewriting the business logic.

• Pros: Meaningful infrastructure and cost benefits with moderate effort; keeps proven business logic intact; lower risk than a rewrite.
• Cons: The application is still fundamentally the old application; agility gains are limited and the code-level skills problem persists.
• Best for: Organisations wanting cloud and cost benefits while preserving working logic and limiting risk.

Refactor

Restructure and improve the existing code, and often convert it to a modern language, without changing its external behaviour. This is where automated COBOL-to-modern-language conversion fits, producing maintainable code in a language with a healthy developer pool.

• Pros: Solves the skills problem by moving to a mainstream language; improves maintainability; preserves behaviour; can be done incrementally.
• Cons: More effort than rehost or replatform; requires rigorous output-parity testing; automated conversion still needs human work on data access and precision.
• Best for: Systems whose logic is sound but whose language and structure are the liability. This is the sweet spot for most COBOL modernisations.

Rearchitect / Rewrite

Rebuild the system, redesigning its architecture (for example into services or a cloud-native design) and re-implementing the business logic on a modern stack.

• Pros: Delivers the most modern, agile, maintainable result; removes accumulated technical debt entirely.
• Cons: The highest cost, longest timeline, and greatest risk; re-implementing decades of undocumented business rules from scratch is where big programmes fail.
• Best for: Systems that are genuinely unfit for purpose, where the business needs capabilities the current design cannot support.

Replace and Retire

Replace the system with a commercial off-the-shelf or SaaS product, or retire it entirely if it is no longer needed.

• Pros: Can be the most cost-effective outcome when a suitable product exists or the function is obsolete.
• Cons: COTS rarely matches bespoke logic exactly; migration and change management are significant; not viable for truly differentiated systems.
• Best for: Commodity functions (for example payroll or general ledger) where a mature product exists.

Comparing the Strategies

How to Choose

Let the business drivers decide, not the technology:

• Primary driver is cost and hardware exit, quickly: start with rehost or replatform.
• Primary driver is the skills shortage and maintainability: refactor, typically converting COBOL to a mainstream language.
• Primary driver is new capability the old design cannot support: rearchitect or rewrite the parts that need it.
• The function is a commodity: consider replace.

In practice, large UK estates blend approaches: replatform the stable parts, refactor the code that is hard to maintain, rewrite the handful of systems that need new capability, and retire what is no longer used. If the chosen path involves converting COBOL to a modern language, the COBOL migration overview compares target languages such as C#, Java, Python, Go, C++, and Rust, and the COBOL migration cost guide sets out realistic budgets.

The Mecanik legacy mainframe migration service covers the infrastructure decommission alongside the code migration, and the COBOL modernisation service covers the code-level refactor and conversion work.

Key Takeaways

• Mainframe modernisation is a choice between rehost, replatform, refactor, rewrite, and replace/retire, each with a distinct cost-risk profile.
• Rehost is fastest and cheapest but modernises the least; rewrite is the most transformative but the most expensive and risky.
• Refactoring (often converting COBOL to a modern language) is the sweet spot when the logic is sound but the language and skills are the problem.
• Most large programmes blend strategies across the estate; let business drivers, not technology preference, decide.

Frequently Asked Questions (FAQ)

What is the difference between rehosting and refactoring a mainframe application? Rehosting (“lift and shift”) moves the existing application onto new infrastructure with the code largely unchanged, so it addresses hardware cost but not the code or skills problem. Refactoring restructures and often converts the code to a modern language while preserving behaviour, which solves the maintainability and skills problem.

Is it better to rewrite or migrate COBOL? It depends on the system. If the business logic is sound but the language is the liability, converting (refactoring) COBOL to a modern language is usually lower risk and cost than a rewrite. A full rewrite is justified only when the current design cannot support the capabilities the business needs.

Which mainframe modernisation strategy is cheapest? Rehosting is typically the cheapest and fastest, but it delivers the least modernisation because the application stays fundamentally the same. Replatforming adds moderate benefit for moderate cost. Rewriting is the most expensive.

Can we modernise a mainframe incrementally? Yes. Incremental (strangler fig ) modernisation replaces or converts parts of the system one at a time, reducing big-bang risk. Most large UK programmes blend strategies and roll out incrementally across the estate.

What is the biggest risk in mainframe modernisation? Re-implementing decades of undocumented business logic, especially in a full rewrite, and inadequate output-parity testing. Strategies that preserve proven logic (replatform, refactor) carry less of this risk than a ground-up rewrite.