Strike While the (Big) Iron's Hot
Source: Dev.to
Making Legacy System Transformation Simple, Fast, and Safe
Mainframe modernization projects often fail due to ever‑climbing development costs and ever‑receding delivery dates. These failures stem from under‑estimating complexity and attempting ambitious transformation before laying the groundwork for safe, efficient change.
Modernization can be efficient, effective, and safe with the right strategy and some good tools.
Proposed Three‑Phase Approach
- Rewrite – Translate COBOL to portable, unit‑tested Java.
- Replatform – Move Java code from z/OS to the cloud.
- 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, enabling gradual skill and knowledge transition, and avoiding the trap of ever‑expanding systems and costs.
Why Modernization Projects Fail
Legacy systems are difficult to maintain and test. Success comes from making the software easier to change before attempting transformation – in other words, “strike only after you’ve made the iron hot.”
Characteristics of Legacy COBOL Applications
- Lack of automated safety nets – No unit‑test library, CI/CD pipeline, or smoke‑test suite to catch unintended consequences.
- Tightly coupled monoliths – Most components are multi‑purpose, making isolation or extraction extremely hard.
- Zero fault tolerance – They process life‑or‑death transactions (Medicare, Social Security, unemployment, etc.).
- Hardware‑efficient design – Optimized for IBM hardware over decades, leaving little performance budget for inefficient changes.
- Continuous regulatory flux – No “freeze period” for major transformations.
When all of these challenges coexist, it’s easy for development teams unfamiliar with them to underestimate the difficulty of transforming legacy systems.
Common Misconceptions of Modernization Teams
- Assuming waterfall is the only barrier – Believing Scrum can be adopted instantly without addressing deeper architectural issues.
- Viewing legacy design as incidental – Treating the system’s architecture as a relic of “developers didn’t know any better.”
- Using archaeology metaphors – Describing the discovery process as “digging up artifacts” while ignoring the expertise of the people who maintain the system daily.
Bright, capable engineers often excel with modern stacks, but they quickly find themselves entangled in unexpected constraints and excessive integrations with the legacy system. Their Scrum ceremonies become mere transparency mechanisms rather than true enablers of agile development.
Every thread they pull seems to threaten to unravel the entire sweater. Every goal or deadline set seems to soften or recede in the face of late‑discovered constraints.
When teams spend sprint time on low‑level technical details just to fill demo slots, project managers should sound the alarm and ask hard questions about return on investment.
A Thought Experiment
Forget the mainframe for a moment. Imagine you inherit a massive software system—millions of lines of code—and it’s your sole responsibility for the next twenty years.
- First change request arrives: modify processing rules, expand data models, and adjust auditing/reporting subsystems.
- You dive into the code and discover a monolithic Rube‑Goldberg machine with no tests.
- Tweaking a cryptically named flag that appears in many places sends a shiver down your spine because you can’t predict side effects.
If you’re like most engineers, your instinct is to write tests before you start tweaking—you know unintended side‑effects can divert millions of life‑saving dollars. If that resonates, the suggestions that follow should feel like common sense.
Key Takeaway
Successfully modernizing complex legacy systems requires laying the groundwork for making transformative changes safely. The three‑phase approach (Rewrite → Replatform → Rearchitect) provides a structured path to achieve that goal while controlling risk, scope, and cost.
Phase 1 – Rewrite → Portable, Tested Java
Goal: Transform COBOL programs into portable, thoroughly tested Java code.
Note: This is not about the low‑quality “JOBOL” transpilers that flood the market. With modern LLMs, we can produce far better results.
What We Do
- Replace each COBOL program with a function‑and‑interface‑equivalent Java implementation.
- Introduce platform‑abstraction layers so that all platform‑specific code lives behind well‑defined interfaces.
- Write unit tests that verify functional equivalence and serve as a safety net for parallel production testing.
Why It Matters
| Key Benefit | Explanation |
|---|---|
| Test Coverage | Unit‑test coverage dramatically accelerates change verification, making rapid, safe deployments possible. |
| Portability | Abstraction layers let the same code and tests run on any platform (local workstation, z/OS, or cloud). No need to rewrite business rules when you move off the mainframe. |
| Safety through Parallel Testing | Identical function and interface allow you to run the new Java component side‑by‑side with the legacy COBOL version, catching regressions before they reach production. |
Practical Tips
- Program‑for‑program rewrites keep dual‑maintenance costs low and enable quick reintegration.
- Treat the guidance as a framework, not a law—adjust bite‑size work based on interface boundaries and LLM‑driven productivity.
- Focus on stable interfaces that can be exercised in parallel testing while you implement platform abstractions.
Phase 2 – Migrate → Cloud Infrastructure
Goal: Move the tested, portable Java code from z/OS to a cloud environment.
“Cloud migration” can sound like the ultimate finish line, but it brings trade‑offs that must be weighed carefully.
Benefits of the Cloud
- Pay‑as‑you‑go hardware resources → flexible cost model.
- Built‑in redundancy across multiple data‑centers → improved disaster‑recovery capabilities.
- Separate CI/CD pipeline → easier deployments that don’t interfere with mainframe release cycles.
- Access to a vast marketplace of developer productivity, analytics, and monitoring tools.
Challenges to Anticipate
| Challenge | Impact |
|---|---|
| Complexity | Fragmenting an application across platforms makes understanding and troubleshooting harder. |
| Latency | Replacing a sub‑millisecond local call with a ~50 ms API call can threaten batch‑cycle timing at scale. |
| Cost | New cloud resources cost money and don’t instantly offset on‑premises expenses; you’ll also need engineers with cloud‑native skillsets. |
Migration Recommendations
- Start Small – Migrate only substantially large, self‑contained functional components that have clear data boundaries.
- Assess Data Locality – Ensure the component can tolerate any runtime degradation introduced by network latency.
- Limit Cross‑Platform Glue – Minimize temporary integration layers; each one adds cost, drag, and risk.
- Maintain Simplicity – Keep the modernized system lean to preserve speed and reduce maintenance overhead.
Phase 3 – Reshape → Maintainability & New Features
Goal: Refactor or re‑architect the system for better maintainability or begin delivering new functionality.
Now that the application is:
- Easier to change (thanks to modern testing).
- Easier to deploy (thanks to CI/CD pipelines).
the team can safely pursue deeper transformations.
Two Paths Forward
| Path | When It Makes Sense |
|---|---|
| Maintainability‑first | You want to continue improving testability, modularity, and overall code health before adding new features. |
| Feature‑first | You have a backlog of user‑experience improvements or business‑critical features that can now be delivered safely. |
Why This Works
- The Rewrite phase deliberately avoided major redesign, leaving the codebase stable and well‑tested.
- With that safety net in place, refactoring (e.g., extracting services, introducing domain‑driven design) or re‑architecting (e.g., moving to micro‑services) becomes low‑risk.
Final Thoughts
Mainframe legacy applications are large, complex, and mission‑critical. Their functions and structures have evolved into tightly coupled, multipurpose components.
Attempting a wholesale transformation before you fully understand the system and build a safety net is a recipe for disaster—every step feels like stepping on a rake.
“Strike while the iron’s hot.”
Use the momentum from the three‑phase approach, but proceed deliberately, with testing and parallel execution as your guardrails.
Strategy Recommendation
Invest time in making your system easier to change before you try to radically transform it.
- Rewriting COBOL into portable, unit‑tested Java, while preserving functional and interface equivalence,
- protects against scope creep,
- enables parallel production testing, and
- is the most efficient path to software malleability.
This critical first step—moving from COBOL to a more productive language—can be:
- The easiest step if you focus on it exclusively, or
- A constant burden if you ignore the defining challenge of these legacy systems, ultimately deciding whether you sink or swim.
Topics Not Covered Here
- Data modernization
- Interface modernization
- Software utilities that enable COBOL/Java integration (to help you hit the ground running)
- Project planning, management, and success metrics
I may write about these topics if there’s enough interest. I’m always happy to chat about this and more for anyone who’s interested.
Get in Touch
If you like the sound of this strategy and would like help applying it to your particular project, I’d be glad to assist.
- Email: sbwiley@pm.me
- LinkedIn: Sam Wiley
About the Author
Sam Wiley – software engineer and Boring Technology advocate specializing in mainframe modernization.
- Lead developer on a modernization team, building new capabilities from knowledge buried in IBM Redbooks.
- Delivered successful production modernization deployments for software that processes billions of dollars annually.
- Technical advisor coordinating modernization work across multidisciplinary teams, planning and overseeing numerous projects.
- Emphasizes pragmatic, risk‑ and cost‑minimized transformation strategies that balance technical innovation with operational stability.