The system still works. That is the problem.
Somewhere in most established companies there is an application that runs the business, was written by people who retired, and has no test suite. Nobody wants to touch it because the risk of breaking it exceeds any benefit of improving it. So it accumulates: another workaround, another integration bolted to the side, another year where the vendor support contract costs more than the last.
For twenty years the only options were to leave it alone or fund a rewrite that would take three years and probably fail. AI has opened a genuinely new middle path, and it is worth understanding precisely what that path is and is not.
What AI is actually good at here
The realistic capability is comprehension and translation, not autonomous rewriting.
Modern models are remarkably effective at reading a large body of unfamiliar code and explaining what it does. For a team facing 400,000 lines of COBOL with no documentation, that alone changes the economics. The first year of a traditional modernization project is largely archaeology: working out what the system does, which branches are live, and which business rules are embedded in code rather than written anywhere. AI compresses that phase substantially.
Translation between languages is the second capability, and it is real but requires qualification. IBM reports roughly 80 percent code accuracy on COBOL to Java conversions with watsonx Code Assistant for Z. That is a useful number and it is also the reason nobody sane runs this unattended. Twenty percent of a large codebase is a lot of code needing human attention, and the failures are not evenly distributed. They cluster in exactly the gnarly, business critical logic that made the system hard to replace in the first place.
The tool landscape
Mainframe and COBOL specific
IBM watsonx Code Assistant for Z is the most established option for z/OS, COBOL, RPG, and CICS environments, covering understanding, refactoring, and transformation toward Java and more modern architectures. If you are on the mainframe, this is the default starting point.
OpenLegacy takes a different position, focusing on API first modernization. Rather than translating the code, it exposes mainframe functionality through modern APIs so new applications can consume it while the core stays where it is. For organizations that need integration more than replacement, this is often the cheaper and lower risk answer.
Heirloom and TSRI automate translation of legacy languages into modern targets, including languages beyond COBOL such as Ada and PowerBuilder.
General purpose refactoring and analysis
Moderne applies OpenRewrite recipes enhanced with AI, which is a meaningfully different model: deterministic, auditable transformations rather than generative rewriting. For large scale mechanical changes such as framework upgrades across thousands of files, this is usually the right tool, and the determinism matters for review.
CAST Highlight and Kodesage focus on analysis: portfolio level assessment of what you have, where the risk concentrates, and what modernization would cost.
GitHub Copilot, Claude, and Cursor handle the day to day work of a developer inside a legacy codebase. Explaining a function, generating a test for untested code, and proposing a refactor of a specific module. This is less headline grabbing than automated conversion and often produces more value per dollar, because it accelerates the engineers who already understand the domain.
Amazon Q Code Transformation targets a narrower and very common case: upgrading Java versions across a codebase, which is unglamorous work that consumes real engineering months.
The strategy question that comes before the tool
Before evaluating any of these, decide which of four things you are doing. They need different tools and produce different risks.
Understand. You need to know what the system does before deciding anything. Almost everyone should start here, and it is the lowest risk use of AI in this space because nothing changes.
Encapsulate. Leave the system running and expose it through APIs. Fastest time to value, and it defers rather than removes the underlying problem.
Refactor in place. Improve the code in its existing language, adding tests and reducing complexity. Good for systems that will live another decade.
Replatform or rewrite. Translate to a new language or architecture. The most expensive and the only one that fully removes the legacy burden.
The most common expensive mistake is jumping to the fourth because AI made it look cheap. Translation tools genuinely reduce the cost of the code conversion step, but code conversion was never the hardest part. Testing, data migration, parallel running, and organizational change were, and none of those got cheaper.
For systems where the target is a modern hosted environment, the sequencing overlaps heavily with a cloud migration roadmap, and the failure modes are the same ones covered in avoiding the pitfalls of a cloud migration.
Where translated code goes wrong
Worth knowing before you trust a conversion percentage.
Business rules encoded in behavior, not logic. Legacy systems frequently depend on ordering, timing, or numeric precision quirks that are not visible as rules. A faithful translation of the syntax can be an unfaithful translation of the behavior, and this surfaces in production rather than in review.
Dead code that is not dead. Static analysis will identify branches that appear unreachable. Some of them run once a year at fiscal close. Removing them is invisible until it is catastrophic.
Idiomatic drift. Converted code tends to be structurally COBOL written in Java syntax. It compiles, it passes tests, and it is unpleasant to maintain, which means you have traded one legacy burden for a newer one.
Missing tests as the real blocker. You cannot safely verify a translation of a system with no test suite. Often the highest value first use of AI is generating characterization tests against the existing system, so you have a baseline to verify anything against. Teams that skip this step are comparing the new system against nothing.
A sequence that works
- Assess the portfolio. Which systems carry the most risk and the most cost. Not everything needs modernizing, and some things should be retired rather than translated.
- Use AI to build understanding. Generate documentation, dependency maps, and business rule extraction from the code itself. Have the people who know the domain review it, because the model will be confidently wrong in places.
- Generate characterization tests. Capture current behavior, including behavior nobody intended. This is your safety net for everything that follows.
- Pick the strategy per system, not per portfolio. Encapsulating one and rewriting another is normal.
- Convert incrementally with parallel running. Never a single cutover on a system that runs the business.
- Budget for the twenty percent. Plan the engineering time for what the tool does not handle, because it is the hardest fifth.
The cost of system downtime is the number that should size step five. Teams that calculate it honestly rarely choose a big bang cutover afterwards.
Security considerations people miss
Legacy modernization involves sending your most sensitive source code to a third party model. That is worth a deliberate decision rather than an assumption.
Ask whether the code is used for training, where processing occurs, and whether your contracts or regulatory obligations permit it. For defense, healthcare, and financial systems this frequently rules out the convenient option and points toward on premises or dedicated tenancy deployments.
There is also a quieter issue. Legacy systems often contain embedded credentials, hardcoded endpoints, and security assumptions that made sense on an isolated network. A translated system deployed to a modern environment inherits those assumptions into a context where they are no longer safe. Modernization is the right moment to fix that, and a poor moment to discover it. Our cloud migration work treats that review as part of the move rather than a follow on project, and the same thinking applies to integrating cloud services with existing infrastructure.
What realistic success looks like
A modernization program going well does not look like a dramatic cutover. It looks like documentation existing where none did, a test suite covering the critical paths, one or two lower risk systems already moved, and an engineering team that is no longer afraid of the codebase.
That last one is underrated. Much of the cost of legacy systems is not technical. It is that changes take six weeks because nobody is confident, and that confidence is what good comprehension tooling actually restores. A healthcare client of ours saw exactly this pattern during a hospital IT modernization: the sequencing and the confidence mattered more than the tooling choice.
Where Mindcore fits
Matt Rosenthal, Mindcore’s CEO, is direct about modernization projects: the ones that fail are almost never the ones that picked the wrong tool. They are the ones that started converting before they understood what they had, then discovered the gap under a deadline.
That shapes how we approach this work. The decision about which systems to modernize and in what order belongs to you, because it is a business decision about risk and cost rather than a technical one. What we contribute is the assessment that makes the decision informed, the security review that stops old assumptions traveling into a new environment, and the infrastructure work underneath it. For systems already headed toward hosted infrastructure, our infrastructure cloud services coverage explains what the destination should look like.
Frequently Asked Questions
Can AI fully automate a legacy system rewrite?
No, and the vendors reporting the best numbers do not claim it. Around 80 percent conversion accuracy is achievable on well understood language pairs like COBOL to Java, but the remaining portion concentrates in the most business critical logic. Treat these tools as a large accelerator on the mechanical work, not a replacement for engineering judgment.
Should we modernize or just encapsulate with APIs?
Encapsulation is faster, cheaper, and lower risk, and it is the right answer when your real problem is integration rather than maintenance cost. Full modernization makes sense when the system is genuinely expensive to maintain, when support is ending, or when the skills to keep it running are disappearing.
Is it safe to send proprietary source code to an AI model?
It depends entirely on the deployment. Ask whether your code trains shared models, where processing occurs, and what your contracts and regulators permit. Regulated industries frequently need on premises or dedicated tenancy options, which exist but cost more.
What should we do first if our legacy system has no tests?
Generate characterization tests that capture current behavior before changing anything. Without a baseline you cannot verify that a modernized version behaves the same, and this is the single most common reason modernization projects lose confidence partway through.
How long does an AI assisted modernization actually take?
Shorter than the traditional equivalent, but measured in quarters rather than weeks for any system that matters. The comprehension phase compresses the most, often dramatically. Testing, data migration, and parallel running compress very little, and those usually dominate the timeline.
Ready to find out what your legacy systems actually cost you?
Most companies carry at least one system everyone works around and nobody has assessed. Putting a number on its maintenance cost, its risk, and its realistic modernization path is a short exercise that tends to change the conversation.
If you want that assessment for your environment, book a free strategy call with our team.
