Rehost, refactor or rearchitect: choosing a mainframe modernization strategy

← All posts

The 3 possible strategies

The vocabulary here descends from the cloud migration “6 strategies” framing, sometimes extended to 7 Rs. We’ll consider the 3 most common for mainframe work.

Rehost. Move the workload to different infrastructure with the code substantially unchanged. On mainframe estates this usually means running COBOL on a Linux or cloud emulator, or recompiling to run on x86. The language stays COBOL. The business logic isn’t touched.

Refactor. Convert the source to a modern language while preserving behaviour. COBOL becomes Java or C#. The structure may be improved, the architecture stays broadly equivalent, and the business rules are carried across intact.

Rearchitect. Redesign the system around a different architecture. Monolith becomes services. Batch becomes event-driven. The business rules get re-expressed rather than translated.

There’s a fourth option people forget: retain. Leaving a system alone is a legitimate decision, and we’ve argued that most of your legacy estate should be left alone. Not every workload earns a modernization budget.

The year 3 comparison

Here’s the table that matters. Timings and costs are directional, drawn from published industry ranges rather than from any single project.

The last row is the one worth arguing about.

Rehost: fast, cheap, and it defers the decision

Rehosting delivers real value quickly. Published figures put MIPS cost savings at 40% to 60%, and timelines commonly at 6 to 12 months. If your immediate problem is a hardware refresh you can’t justify or a mainframe bill growing 10% to 15% a year, rehosting solves that problem this financial year.

It doesn’t solve the others.

After a rehost, the code is still COBOL. The developers who can maintain it are still the ones retiring at a rate of roughly 85,000 a year globally, and the salaries are still climbing. Change velocity is unchanged, because the reason a change takes 6 months was never the hardware. It was the absence of tests and the fear of hidden dependencies.

You’ve also acquired a new dependency. Emulation and recompilation approaches typically require a runtime or a licence, so a one-off project cost becomes a recurring platform cost. That’s not automatically bad, and it should be modelled over 10 years rather than 3.

Where rehost is genuinely the right call:

• Hardware refresh is imminent and the capital cost is the trigger
• The application has a defined end of life within 5 years
• You need to exit a data centre on a fixed date
• The estate is genuinely stable and change volume is near zero

Where it becomes an expensive detour: when the underlying driver was skills or change velocity, and someone chose the cheap option because the business case was easier to write. Those organisations run a second programme within 4 years, and the second programme starts from a hybrid estate that’s harder than the original.

We’ve covered the specific case of cost-only projects in the MIPS and mainframe cost discussion.

Refactor: the middle path, and often the right one

Refactoring converts the source to a modern language while preserving what the system does.

The appeal is that it addresses the actual constraints. The language changes, so the hiring pool changes. The code becomes testable with mainstream tooling. The platform becomes cloud-capable. And because behaviour is preserved rather than redesigned, the risk stays bounded.

The critique of refactoring is well known and worth taking seriously: literal conversion can produce ava or C# that compiles and runs but still has the structure and maintenance characteristics of COBOL.”Sometimes referred to as “Jobol”, meaning code that inherits legacy maintenance problems without the mainframe’s performance characteristics.

That outcome is real, and it’s a property of the conversion approach rather than of refactoring as a strategy. Output structure is a choice. Conversion that maps COBOL paragraphs to methods, REDEFINES to proper type hierarchies, and level-88 conditions to domain types produces something a Java developer recognises. Conversion that transliterates statement by statement doesn’t.

So the question to ask isn’t whether to refactor. It’s what the output looks like, which means asking to see generated code from a comparable project before you commit.

Two other things refactoring gets right that matter in year 3.

Business rules survive. In a 30-year-old estate, the code is the specification. Nobody has a document that says what happens when a policy lapses on the 29th of February in a leap year, but the COBOL knows. Translation carries that across. Redesign asks someone to remember it.

The verification problem is tractable. Comparing behaviour between an old system and a functionally equivalent new one is a well-defined exercise. You can run both against the same inputs and diff. Comparing an old system against a redesigned one isn’t a diff, it’s a judgment call on every difference.

Our COBOL to Java migration and COBOL to C# pages cover how this works in practice, and four ways to modernize legacy code sets refactoring alongside the alternatives.

Rearchitect: the highest ceiling and the highest failure rate

Rearchitecting is the only strategy that gets you a genuinely different system. Services, event-driven processing, independent deployment, elastic scale. If the business case depends on capabilities the current architecture can’t express, this is the option that delivers them.

It’s also where the expensive failures cluster.

Published cost figures put full rearchitecture at $4 million and up with 24 to 48 month timelines, and both numbers have a long right tail. The failure mode is consistent across the case studies: the programme runs out of sponsor patience before it runs out of scope.

Three specific traps.

Rebuilding the specification from memory. Rearchitecture requires knowing what the system does, and the estate you’re replacing is the only complete record. Business rules extraction helps, and it produces an input rather than a finished specification, which is a distinction we’ve written about elsewhere.

Scope with no exit condition. Redesign invites improvement. Every workshop surfaces something worth fixing, and the scope grows quarterly. Programmes that begin without a hard definition of done rarely acquire one later.

The parallel estate. During a multi-year rearchitecture you’re running the old system and building the new one, paying for both, and maintaining bridging code between them. This is why the strangler fig pattern is popular, and also why so many strangler migrations stall around 40% complete, which we’ve analysed in why most strangler fig migrations stall.

Where rearchitecture is the right call:

• The business capability genuinely requires an architecture the current system can’t support
• The system is small enough to rebuild within a single sponsor’s tenure
• You have a complete and current specification, or the domain is simple enough to re-derive
• The existing system is well understood by people still employed

If 3 of those 4 aren’t true, sequencing matters more than ambition.

The sequencing argument

Here’s the position worth taking. For most large estates, refactor then rearchitect beats rearchitect directly.

The logic is about what each phase makes possible.

Refactoring first gets you to a mainstream language on a modern platform with behaviour preserved and, if done properly, a regression suite built during validation. That’s a stable base.

From there, rearchitecture becomes an ordinary engineering programme. You have tests. You have developers who can read the code. You can extract a service, verify it against the suite, deploy it, and repeat. Each step is reversible and independently valuable.

Rearchitecting directly from COBOL means doing the language change, the architecture change and the specification reconstruction simultaneously, with no test suite and no rollback point. Every one of those is hard. Doing them together is how programmes reach month 30 with nothing in production.

The counter-argument is that this is 2 projects and costs more in total. Sometimes true. It’s also the version that survives a sponsor change in month 18, and sponsor changes are more common than modernization programmes are short.

What the platform vendors have changed

Worth noting how the landscape shifted, because it affects the decision.

The hyperscalers now offer agentic tooling across these paths. AWS Transform offers both a refactor route and a “reimagine” route that targets microservices. IBM watsonx Code Assistant for Z targets refactoring while keeping workloads on IBM Z. Google’s mainframe assessment tooling focuses on discovery and rules extraction.

Two implications for your decision.

First, discovery and documentation got cheaper. Gen AI is genuinely good at generating documentation for undocumented programs and drafting test cases, and that’s an augmentation layer worth using regardless of which strategy you pick.

Second, the target platform is now part of the strategy choice in a way it wasn’t before. Some of these paths assume a specific cloud, or a specific runtime. If platform independence matters to you over 10 years, ask where the output runs and whether it runs anywhere else.

What each strategy does to your team

The org chart consequence gets discussed less than the cost, and it usually outlasts it.

After a rehost

Your team composition is unchanged. You still need COBOL developers, and you’re still competing for them in a market where US salaries sit around $115,000 to $125,000, contract rates run $100 to $180 an hour, and roles take 2 to 3 times longer to fill than modern-stack equivalents.

You’ve also added a new skill requirement. Someone has to understand the emulation or recompilation layer, which is a specialised platform skill with a smaller talent pool than either COBOL or Java.

Net effect on hiring: slightly worse.

After a refactor

The maintenance pool becomes mainstream. Java and C# developers are available, affordable and replaceable, which changes both cost and continuity risk.

The transition matters here. Your COBOL developers understand the business domain better than anyone you’ll hire, and the sensible move is retraining rather than replacement. Domain knowledge takes years to build and language syntax takes months, so the arithmetic favours keeping them.

Programmes that treat conversion as a reason to release the COBOL team lose the knowledge that validation depends on. We’ve written about this in the talent shortage for legacy code.

Net effect on hiring: substantially better, provided you retain the domain knowledge through the transition.

After a rearchitect

Best case, you have a modern system that a modern team can extend, and hiring is straightforward.

The risk is different. Rearchitecture usually distributes what was a single system across services, which needs platform engineering, observability and distributed systems skills the previous team didn’t require. That’s a capability build, and it needs to be in the plan rather than discovered at go-live.

Net effect on hiring: best ceiling, highest capability build required.

Modelling the 10-year cost

Most business cases run 3 to 5 years, which is exactly short enough to make rehosting look best. Extend to 10 and the ranking often changes.

Four lines to include that standard models tend to miss.

Platform licence tail. Rehosting to an emulator or a recompilation runtime creates a recurring cost that continues indefinitely. Over 10 years that can exceed the difference in project cost between rehosting and refactoring.

Salary drift on scarce skills. COBOL salaries have been rising faster than general developer salaries, driven by supply. Modelling them flat for 10 years understates the run cost of any option that keeps COBOL.

Change velocity as revenue. Hard to quantify and usually the largest number. If a product change takes 6 months on the current platform and 6 weeks on a modern one, and the business ships 8 significant changes a year, the compounding effect over a decade is larger than the entire migration cost.

Probability-weighted second project. If rehosting carries a 60% chance of a follow-up modernization within 5 years, the expected cost of rehosting includes 60% of that programme. Very few business cases include this line, and it’s frequently the one that flips the comparison.

None of these are exotic. They’re just outside the window most business cases use.

Three patterns worth recognising

Composite patterns from how these decisions play out. Not specific engagements.

The data centre exit. A retailer with a lease expiring in 14 months and a stable COBOL estate that changes twice a year. Rehost is unambiguously correct. The driver is a date, the estate is stable, and the skills problem is real but not urgent. They’ll revisit in 5 years and that’s fine.

The compliance clock. An insurer with unsupported components in a regulated system and an audit finding to close. Refactor, waved, starting with the components named in the finding. Rearchitecture is too slow to satisfy the date, and rehosting doesn’t remove the unsupported component. The regulatory framing is covered in security debt as a modernization deadline.

The ambitious rebuild. A payments business that decided to rearchitect a core platform directly from COBOL, without a test suite, while redesigning the data model. Month 30, nothing in production, sponsor changed, programme cancelled. The restart began from a partially converted estate with bridging code, which was harder than the original problem.

The third pattern is common enough to be worth designing against explicitly.

A decision framework

Work through these in order. The first clear answer usually settles it.

1. What’s the actual driver?

• Cost only, on a stable system with an end date in sight: rehost.
• Skills, change velocity or platform capability: refactor or rearchitect.
• Regulatory pressure on unsupported components: refactor, because it’s the fastest route to a supported stack.

2. How well do you understand the system?

• Complete specification, people who built it still present: rearchitect is viable.
• The code is the only specification: refactor, and carry the rules across.

3. How long is your sponsor’s runway?

• Under 2 years: rehost or a waved refactor with value at each wave boundary.
• 3 years or more with committed funding: rearchitect is on the table.

4. What happens in year 3 if you do nothing more?

• Rehost: still COBOL, still hiring COBOL people, still slow to change.
• Refactor: mainstream stack, mainstream hiring, improved velocity.
• Rearchitect: best outcome if it completed, worst if it didn’t.

5. What’s your tolerance for a second programme?

If a follow-up programme in 4 years is politically survivable, rehost is a reasonable staging move. If it isn’t, don’t choose the option most likely to require one.

The questions that reveal which strategy a vendor is really selling

Vendors describe their offering in the language of whichever strategy the buyer prefers, so the labels are unreliable. These 6 questions establish what you’re actually being offered.

1. What language is the code in after the project?

If the answer is COBOL, it’s a rehost regardless of what it’s called. That isn’t a criticism, it just needs to be understood.

2. Does the output run without your runtime?

Some approaches produce code that only executes against a proprietary layer. That converts a project cost into a permanent platform cost, and it constrains where you can run in future.

3. Is the architecture after the project equivalent to the architecture before?

If yes, it’s a refactor. If the answer involves services and event streams, it’s a rearchitecture, and it should be priced and scheduled as one.

4. Who decides what the system is supposed to do?

If the answer is “the existing code”, behaviour is being preserved. If it’s “a workshop with the business”, the specification is being reconstructed, which is the highest-risk activity in this whole space.

5. What happens to the business rules nobody remembers?

Translation carries them. Redesign requires someone to rediscover them. This single question separates the risk profiles more cleanly than any other.

6. When can the mainframe be switched off?

If the answer is “at the end”, there’s no interim saving and the business case depends entirely on completion. If it’s “progressively, as waves complete”, the programme funds itself.

A note on hybrid outcomes

The framing above treats this as a single choice for the whole estate, which is rarely how it should work.

Large estates contain workloads with genuinely different profiles. A batch reporting suite that changes twice a decade has different economics from a customer-facing transaction system that the business wants to change monthly.

Segmenting by change volume and business criticality usually produces a sensible mixed answer: retain the stable low-risk workloads, refactor the ones where skills and velocity matter, and rearchitect only the small subset where a genuinely different capability is required.

The mistake is applying one strategy uniformly because it’s simpler to govern. That optimises for programme management convenience at the cost of spending refactoring budget on code that should have been left alone, which is the argument in most of your legacy estate should be left alone.

Segmentation should come out of the assessment phase, before the strategy is chosen. It’s the deliverable that makes the strategy question answerable rather than ideological.

Frequently asked questions

Is rehosting a waste of money?

No. It’s the right answer when the driver is infrastructure cost or a data centre exit and the estate is stable. It becomes expensive when it’s chosen to avoid a harder conversation about skills and change velocity.

Can we rehost now and refactor later?

Yes, and it’s a common sequence. Model the emulator or runtime licence cost across the full period, because the interim platform cost sometimes exceeds the saving that justified it.

Does refactoring always produce unmaintainable code?

No. Output structure depends on the conversion approach. Transformation that maps COBOL constructs to idiomatic target-language equivalents produces code developers can work with. Ask to see real generated output before committing.

Which strategy is fastest to a supported, compliant stack?

Refactoring, usually. Rehosting can leave unsupported components in place, and rearchitecture takes too long to satisfy a near-term compliance date.

How do we decide between Java and C# as a target?

Existing skills and platform strategy, more than technical merit. Both are appropriate targets. Java has a larger enterprise ecosystem for high-throughput batch, C# suits organisations already invested in .NET and Azure.

What about a hybrid, where some workloads move and others stay?

Common and often correct. Segment by change volume and business criticality. Systems that never change and carry low risk can stay where they are, which is the argument in when not to modernize legacy systems.

What to do in the next 30 days

Whichever direction you’re leaning, the same 4 steps make the decision defensible.

1. Inventory the estate and segment it. Programs, lines, dialects, data stores, change volume per module over the last 3 years. Change volume is the segmentation variable most organisations don’t have and most need, because it separates the code that deserves investment from the code that doesn’t.
2. Establish the run-rate baseline. Current mainframe total cost of ownership, licence renewals due, hardware refresh dates, headcount on legacy skills and the age profile of that headcount. Without this, no strategy comparison is possible, because you have no denominator.
3. Identify the hard dates. Lease expiries, licence renewals, audit findings, regulatory deadlines, hardware end of support. Hard dates rule strategies in and out faster than any technical analysis, and they’re usually already known somewhere in the organisation.
4. Get a complexity read on the code itself. Dialects present, dynamic dispatch usage, embedded languages, data layer shape, dead code proportion. This is what tells you whether refactoring is straightforward or difficult on your specific estate, and it’s the input that most changes the answer.

Those 4 take 4 to 6 weeks and cost a fraction of any of the options they’re informing. Organisations that skip them choose a strategy from a slide deck and discover the constraints afterwards.

Next step

The strategy question is easier to answer with a complexity profile of your own estate in front of you, because the code usually rules out at least one option.

Modernize Software runs a free codebase assessment that produces the inventory, dependency graph and complexity analysis this decision needs.

If you’re leaning toward refactoring, the modernize COBOL hub covers the approach, and the DMS platform page explains the transformation technology underneath it.