Mainframe modernization projects have a reputation for runaway costs and receding delivery dates — but it doesn't have to be that way. With the right strategy, modernization can be efficient, effective, and safe.

The approach we recommend at Verdance prioritizes software malleability: making your system easier to change, test, and deliver before attempting ambitious transformation. This three-phase strategy minimizes risk and cost while yielding tangible, measurable progress at every step:

1. Rewrite — Translate COBOL to portable, unit-tested Java

2. Replatform — Move Java code from z/OS to the cloud

3. Rearchitect — Refactor and reshape for improved maintainability and new capabilities

By proceeding through these phases in tightly scoped iterations, modernization can make steady progress while maintaining system stability and enabling gradual skill and knowledge transition.

Why software malleability comes first

When we talk about software malleability, we mean something specific: how easily a system can be changed, tested, and verified safely. A highly malleable system has unit tests that can be run at the press of a button, a CI/CD pipeline with quality gates, and automated safety nets that catch unintended consequences before they reach production. A system with low malleability has none of these things — and legacy COBOL systems almost universally fall into that category.

This isn't an accident or an oversight. COBOL applications have evolved over decades, accumulating business logic, regulatory changes, and institutional knowledge along the way. The defining challenge they present isn't their age or their language — it's the near-universal absence of a unit testing framework. Without one, verifying any change requires significant manual effort and the expertise of the humans who have been maintaining that particular system for years or decades. Every modification carries real risk: these systems process transactions that can have life-or-death consequences, and a subtle, unintended side effect can misdirect millions of dollars in benefits or break critical audit trails.

This is why software malleability is the first priority. The most cost-effective thing you can do before transforming a legacy system is to build the safety net that makes change safe. Once you have that, everything else — migration, rearchitecting, new feature development — becomes dramatically more tractable. Build the safety net first, then use it.

Phase 1: Rewrite (COBOL to Java)

Goal: Transform COBOL programs into portable, thoroughly tested Java code. The first phase focuses on producing function-and-interface-equivalent Java replacements for your COBOL programs — not redesigning them, just translating them into a more productive language with proper test coverage and platform abstraction.

Constraining rewrites to functional and interface equivalence is a deliberate choice. It protects the work from scope creep, keeps dual-maintenance costs low during the transition, and — critically — enables production parallel testing: running old and new implementations side-by-side (or re-running historical inputs and outputs) to verify that outputs match before cutting over.

What this phase delivers:

• Test coverage. Unit tests dramatically accelerate change verification and make it safer to deploy updates quickly. This is the foundation everything else builds on.

• Portability. Abstraction layers for platform-specific code mean your Java programs and their tests can run anywhere — on a developer's local machine, on z/OS, or in a cloud CI/CD pipeline — without rewriting business rules.

• A repeatable safety net. Parallel production testing gives you a reliable, low-risk path to cut over each rewritten component while protecting against accidental changes to production behavior.

A note on scope: going program-for-program is a guideline, not a law. The goal is right-sized bites of work defined along stable interface boundaries. With recent improvements in LLM-assisted translation, rewrites can move faster than ever — but the principle of keeping interfaces stable for parallel testing remains the key design constraint. We're open-sourcing the platform abstractions and LLM prompts that make this phase repeatable, including the portability layers that let translated Java run on z/OS, in the cloud, or on a developer's laptop without changing business logic.

Phase 2: Replatform (z/OS to cloud)

Goal: Move tested, portable Java code from z/OS to cloud infrastructure.

With portable, well-tested Java in hand, migrating to cloud infrastructure becomes a much more tractable problem. The benefits are real: pay-as-you-go hardware flexibility, configurable redundancy for disaster recovery, deployment pipelines independent of mainframe release cycles, and access to a broad ecosystem of developer productivity, analytics, and observability tools.

That said, replatforming introduces its own tradeoffs worth keeping in mind:

• Complexity. Fragmenting an application across platforms makes it harder to understand and troubleshoot as a whole.

• Latency. Replacing a sub-millisecond local program call with a 50ms API call at scale can threaten batch cycle timing requirements.

• Cost. New cloud infrastructure adds cost before it reduces on-premises expenses, and brings additional skillset requirements with it.

For these reasons, we recommend replatforming only substantially large, cohesive functional components at a time — not piecemeal migration. Data locality, runtime performance budgets, and the overhead of maintaining cross-platform connective tissue are all factors in deciding how much to move at once. The goal is to keep the system as a whole understandable and maintainable throughout the process. Simplicity and lean scope are what sustain project momentum.

It's also worth noting that fully moving off the mainframe will eventually require addressing two areas this post doesn't cover: data modernization and interface modernization. Many legacy systems still rely on VSAM data stores and present users with 24x80 green screen CICS interfaces — neither of which belongs in a cloud-native architecture. Modernizing these layers is real work with its own strategies and tradeoffs, and it's work we have experience with and opinions about at Verdance. If your program is approaching that stage, we'd welcome the conversation.

Phase 3: Rearchitect (monolith to modular)

Goal: Reshape your system for improved maintainability, or begin exploring new capabilities.

By the time you reach this phase, your application is in a fundamentally different position: it's easier to change, easier to test, and easier to deploy. The groundwork laid in the first two phases makes more ambitious transformation genuinely achievable rather than aspirational.

This is where your team's accumulated knowledge of the system — and its pain points — can be put to use. Refactoring for cleaner boundaries, improving testability, decomposing the monolith into more manageable modules, or beginning to develop new features and user-facing capabilities are all on the table. The right priorities will depend on your program's goals and constraints, but the key difference is that you're now making these decisions from a position of stability rather than urgency.

Simplicity enables speed

Mainframe legacy applications are large, complex, and mission-critical. The strategy above is designed to respect that complexity rather than work against it — building the safety net before swinging for transformative change.

Rewriting COBOL into portable, unit-tested Java, constrained to functional and interface equivalence, is the most efficient path to software malleability. It's the step that makes everything else easier, faster, and safer. Skipping or shortchanging it tends to make every subsequent step harder than it needs to be.

If your organization is looking for a pragmatic, risk-minimized path through mainframe modernization, we'd be glad to talk through how this approach applies to your particular system.