Re-Host, Refactor, or Rewrite?

1. Re-hosting, refactoring, and rewriting solve different problems and deliver fundamentally different outcomes
2. Re-hosting reduces cost fast but does not modernise architecture
3. Refactoring balances speed, cost, and long-term maintainability
4. AI-powered rewriting delivers the cleanest architecture but requires the most time and investment
5. Choosing the wrong approach often costs years and significant capital. Successful modernisation depends on combining and sequencing all three

Re-hosting, refactoring, and rewriting are the three core approaches to mainframe modernisation. They differ fundamentally in cost, speed, risk, and long-term impact.

• Re-hosting moves applications off proprietary infrastructure without changing the code
• Refactoring converts legacy languages into modern ones while preserving logic
• Rewriting rebuilds systems for a new target architecture using AI-assisted reverse engineering

Each approach optimizes for a different outcome cost reduction, maintainability, or architectural transformation. Treating them as interchangeable is one of the most common and expensive mistakes. In large-scale modernisation, they are complementary approaches that must be combined, not chosen in isolation.

Re-hosting, often called lift-and-shift, is the fastest path to reduce mainframe infrastructure cost.

It moves mainframe applications to Linux-based enterprise environments using emulation platforms. The COBOL code remains unchanged, preserving functional behaviour while eliminating proprietary hardware and MSU/MIPS-based pricing models.

This approach is most effective when institutions face immediate cost pressure, tight regulatory timelines, or limited appetite for code-level risk. Programmes typically deliver measurable OPEX reduction within 12 - 18 months and carry lower execution risk than deeper transformation initiatives.

The trade-off is clear: re-hosting reduces cost, not complexity. Developer experience, system agility, and AI readiness remain largely unchanged. The limitation is structural. Re-hosting reduces cost – but does not improve architecture, developer experience, or long-term agility.

Refactoring delivers modernisation benefits without the disruption of a full rewrite.

As a form of application refactoring, automated refactoring converts COBOL, RPG, or PL/I code into modern languages such as Java while preserving business logic. The application behaves the same, but the runtime, tooling, and skills required to maintain it change fundamentally.

This approach reduces long-term talent risk, enables modern CI/CD pipelines, and establishes a foundation that can later support microservices and API-based integration. It is most effective when the codebase is structurally sound and well understood.

Refactoring modernises the language, not the architecture. As part of broader software modernisation initiatives, it is often the first phase of a longer modernisation journey, not the final destination.

Rewriting is necessary when the problem is architectural, not economic.

The condition of the technology stack and the level of code obsolescence are critical factors in this decision. Systems that have evolved continuously over decades without major structural changes often accumulate complexity that limits innovation. Over time, this can make it increasingly difficult to introduce new products, generate business insights from transactional data, adapt business rules, or implement even minor enhancements efficiently.

AI-powered rewriting extracts business logic from legacy systems and re-implements it in a target architecture designed for modern operations, resilience, and AI adoption. The result is not converted code, but a new system with equivalent functionality on modern foundations.

Rewriting is appropriate when codebases are heavily degraded, undocumented, or incompatible with the target architecture. It delivers the cleanest long-term outcome but requires multi-year commitment, strong governance, and higher upfront investment.

The right approach emerges from objective assessment, not preference.
These three questions help define the decision:

• What is the primary objective: cost reduction, modernisation depth, or AI readiness?
• What is the actual condition of the codebase?
• How much time does the programme have?

Modernisation is not about selecting one approach. It is about applying the right approach to each system, and sequencing them correctly.

Large application estates require:

• Re-hosting for immediate for immediate cost relief
• Refactoring for stable, maintainable systems
• Rewriting for complex or strategically critical platforms

The real challenge is not choosing between approaches, it is orchestrating them across the portfolio. That is what determines whether modernisation accelerates, or stalls.