AI in legacy modernization: what actually works in 2026 (and what doesn’t)

- AI works best in legacy modernization as an accelerator, not an autopilot. It shines at reading code, writing documentation, mapping dependencies and generating tests.
- The upside is real: faster delivery, lower technical-debt costs, recovered business logic and better test coverage.
- So is the downside: insecure generated code, unclear ownership of AI output and the temptation to modernize everything at once.
- The approach that works is incremental. Start with AI-assisted discovery, build a test safety net, then migrate module by module with engineers reviewing every change.
Your legacy system still runs critical business operations. But it also blocks cloud migration, new integrations and other projects on your roadmap. Rewriting it by hand can drag on for years, and the people who built it have often retired or moved on, taking undocumented business logic with them.
Now every vendor promises that generative AI will do the job in months. But it isn’t entirely true. Gartner predicts that more than 70% of mainframe exit projects started in 2026 will fail to deliver their intended benefits because buyers overestimate what generative AI tools can actually do.
The good news: used in the right places, AI-driven legacy modernization does cut time and risk. This guide shows where it delivers, where it breaks and what a realistic path forward looks like.
What is AI in legacy modernization?
AI in legacy modernization is the use of large language models (LLMs) and other machine learning techniques to help teams understand, document, test, refactor and migrate aging software systems.
It is not a single tool that converts old code into new code. Instead, it is a set of assists spread across the modernization process, which makes each step faster and cheaper.
Those gains, however, depend on oversight. AI-generated results still need human review to confirm that critical business logic works as expected, so engineers remain the ones who make the decisions.
What AI does well, and what it still can’t do
AI is strongest where the work is reading and pattern-matching at scale:
- Summarizing undocumented code and reconstructing business rules
- Mapping dependencies between modules, databases and external interfaces
- Generating unit and characterization tests that capture how the system behaves today
- Producing first drafts of code translation and API wrappers
It is weakest where the work needs judgment and the system-level context. Gartner’s analysts note that generative AI has significant limits in automated conversion, especially in preserving performance and throughput after a move. That’s why architecture choices, data strategy and performance tuning still need senior engineers.
AI-assisted vs. AI-led modernization
AI-assisted modernization means engineers drive the project and use AI to speed up specific tasks. AI-led modernization means a pipeline of AI agents converts large parts of the system, with engineers reviewing the output.
AI-led sounds faster, and on clean, well-tested code it can be a valid strategy. On complex legacy systems, though, it carries far more risk: without close oversight, an error in one module can spread to others before anyone notices.
Both models share a deeper risk. Converting legacy code doesn’t necessarily modernize the system. McKinsey calls this the “code and load” trap: AI translates outdated code into a modern language, but the original architecture, complexity and technical debt remain. That’s why human input still matters, however much of the work AI does.
Generative AI vs. classic automated conversion
Rule-based converters have existed for decades. They apply fixed mapping rules to syntax, APIs and data types, so the same input always produces the same output, and they report what they couldn’t convert. But they work construct by construct and don’t understand what the code is for, so the result often keeps the old design in a new language. For one example, see our comparison of code converters for VB6 migration.
Generative AI, on the other hand, can explain why code exists and propose idiomatic rewrites, but the trade-off is consistency. The output can vary between runs, and it can produce code that looks right but isn’t, without flagging it.
In practice, the choice is rarely one or the other. Converters handle predictable bulk translation; AI helps engineers understand the code, write tests, resolve what the converter flagged and clean up the output.
When AI for legacy systems makes sense
AI can accelerate modernization, but not every legacy project benefits equally. Below are the four modernization scenarios where AI can help.
Your legacy codebase is large and nobody fully understands it
Millions of lines of code, little documentation, original authors long gone. This is where AI delivers the most value, as long as you use it to understand the system rather than convert it. Automated summaries and dependency maps can turn weeks of code archaeology into days and give your architects a shared understanding of the code before anything changes.
You are moving between mainstream tech stacks
VB6 to .NET or C# and Java EE to Spring Boot. These paths have plenty of public examples that LLMs were trained on, so first drafts are usually a reasonable starting point. Exotic dialects, in-house 4GLs (fourth-generation languages) and heavily customized mainframe code are a different story. There is far less public code for models to learn from, so AI output may need heavy review.
You lack tests and need a safety net first
If you can’t prove the new system behaves like the old one, you can’t switch safely. Models are very good at generating characterization tests from existing code and its behavior. These tests still need validation, but even if you modernize by hand, this alone can justify the investment in AI tools.
You need to modernize in place, without a big-bang cutover
When the system can’t go dark, the safer route is to replace it piece by piece, routing traffic from old modules to new ones until the legacy system can be retired. AI helps find natural seams in the code, drafts API wrappers around legacy modules, and generates contract tests for each boundary.
This approach can be combined with an extension-based design, where new functionality is built as separate extensions, instead of being added to the legacy core. To keep extensions working after old modules are retired, engineers can connect them through the same API wrappers rather than directly to the legacy code.
When to hold back: if your system is small, stable and cheap to run, or if regulators require traceability that you can’t yet provide for AI-generated output, a conventional modernization approach may be the safer call.
Benefits of generative AI modernization
When it is scoped well, AI can reduce the time and effort required to modernize legacy systems.
1. Faster delivery
The headline benefit is speed. AI takes over much of the slow, manual work that stretches modernization projects across years. In its March 2026 report Core Banking Modernization Acceleration Trends, Gartner predicts that by 2028, half of banks will use agentic AI for legacy modernization, and most will see time to deployment improve threefold.
2. Lower technical-debt cost
Servicing technical debt eats up 21-40% of a typical company’s IT spending, according to Deloitte’s 2026 Global Technology Leadership Study. AI makes paying that debt cheaper. It helps teams find and describe it, documents what the code does and generates the tests that make refactoring safe.
3. Recovered business logic
Legacy systems often hold rules that exist nowhere else. AI-generated documentation turns that hidden business logic into something engineers and product owners can review and confirm. Many companies already use AI on their legacy projects: in a 2025 KPMG survey of 135 US technology companies and investors, 52% said they have applied AI for automated refactoring or legacy code analysis.
4. Better test coverage
AI-generated tests can help establish a regression baseline before modernization and verify that the new system behaves as expected. With proper validation, they can significantly shorten QA cycles and reduce the risk of defects reaching production.
How an AI modernization approach compares with the alternatives
AI-assisted modernization is often a good choice for complex systems, but it is not the only path. Here is how it compares with other approaches.
| Approach | Best for | Real trade-off |
| AI-assisted modernization | Complex legacy systems with undocumented business logic, where engineers need tight control over changes | More engineering involvement limits automation gains, but provides greater control over critical changes |
| AI-led modernization | Large-scale, repetitive code transformations with predictable patterns and clear requirements | Higher automation potential, but harder to detect and correct errors across large batches of generated code |
| Manual modernization or rewrite | Small systems or projects with specialized requirements where automated tools offer limited value | Requires more hands-on engineering effort; full rewrites can be costly and time-consuming |
| Rule-based automated conversion | Well-structured codebase on a common language path supported by conversion tools | Fast and predictable for supported patterns, but output often needs heavy refactoring |
Who’s involved and how it works
AI changes the shape of software teams, not the need for them. A typical team on an AI-assisted project looks like this:
| Role | What they own |
| Solution architect | Defines the target architecture, modernization strategy, migration sequencing, and selects appropriate AI tools |
| Senior engineers (old + target stack) | Configure AI-coding tools, review AI-generated code, handle hard refactoring and optimize performance |
| QA automation engineer | Uses AI to generate characterization and regression tests, validates the tests, and verifies that the modernized system behaves as expected |
| DevOps engineer | Manages CI/CD pipelines, infrastructure, deployment automation, monitoring, and rollback procedures |
| Security engineer | Handles security assessments, vulnerability scanning, access control, dependency checks and compliance requirements |
The operational loop is simple. Engineers decide what to modernize and define what the new code must do. AI drafts the code, engineers review it, automated tests confirm it behaves like the original and security scans flag potential vulnerabilities. Code reaches production only after an engineer signs off. This is the approach we follow at Abto Software for AI-powered legacy code modernization.
How to modernize: a 4-phase legacy modernization journey
Below is the process we follow most often. Each phase has a clear exit gate tied to your modernization goals.
Phase 1: Discover and map
- Scan the codebase with AI tools to inventory modules, dependencies, dead code and integration points.
- Generate plain-English summaries of key modules and have business owners confirm the rules.
- Score each module by business value, change frequency and risk.
Exit gate: a prioritized module map that business and technical stakeholders agree on.
Phase 2: Build the safety net
Before you migrate legacy modules, prove what they do today.
- Use AI to draft characterization tests, then run them against the current system to record what it actually does, bugs included.
- Set up CI/CD (continuous integration and delivery) with security scanning on every change.
- Define parity criteria: outputs, performance and throughput the new code must match.
Exit gate: a regression suite that runs automatically and passes on the current system.
Phase 3: Pilot one module
- Pick a module with real value but limited blast radius.
- Use AI to draft the new version, then have engineers then have engineers review, refactor and harden it.
- Run it in parallel with the old version and compare results against your parity criteria.
Exit gate: the pilot meets parity in production, and you have real data on speed-up and on defect rates.
Phase 4: Scale and decommission
- Roll the proven workflow out across legacy modules in waves, following the priorities set in Phase 1.
- Retire old components as each wave stabilizes.
- Track ROI (return on investment) against the Phase 1 baseline so the business sees the gains.
Exit gate: each legacy component is switched off, not just bypassed.
What does the modernization effort cost?
There is no flat price, because cost is driven by the system, not by the tool. Licenses for AI legacy tooling and coding assistants such as GitHub Copilot or Claude Code are a small line item, though usage-based charges can add up when agents run at scale. Engineering time is still the biggest expense.
What drives the price
- Codebase size and complexity: raw size matters, but coupling, custom frameworks and undocumented integrations often matter more.
- Existing test coverage: near-zero coverage turns Phase 2 into a project of its own.
- Language path: mainstream paths (VB6 or .NET Framework to modern .NET) cost less than rare dialects or mainframe code.
- Data migration: schema changes, data cleansing and dual-running often cost as much as the code.
- Compliance scope: HIPAA, PCI DSS or financial regulation such as SOX or DORA add audit trails and review time.
How geography and engagement model affect cost
Rates vary widely. Teams in North America and Western Europe typically charge the most. Providers of modernization services and migration services in Central and Eastern Europe often offer senior engineering at noticeably lower rates, with full working-hour overlap with Western Europe and partial overlap with the US East Coast. South and Southeast Asian teams are usually the lowest-cost option.
Whatever the region, check a team’s AI expertise as closely as its rates. A dedicated team suits multi-year programs; fixed-scope work suits a well-defined pilot.
AI modernization risks and how to keep the gains
AI speeds up modernization, but it doesn’t remove risk. It changes where risk shows up. These are the modernization challenges that sink most projects, with effective practices to keep them in check.
Insecure AI code: treat model output as untrusted
Machine-written code often looks production-ready when it isn’t. In a 2025 study, Veracode tested over 100 LLMs and found security flaws in about 45% of the code they produced, with Java failure rates above 70%.
Teams that write code with AI need the same review discipline as any other contributor. Check every change for security, and make sure it fits the target architecture rather than copying the old design line by line.
No clear ownership: set up governance before you scale
Most companies are behind here. A KPMG’s survey of technology companies and investors found that 79% had no central AI oversight, leaving each department to set its own rules.
Using generative AI could save you months, but only if someone owns its output. For a structure to build on, use the “Govern” function of NIST’s AI Risk Management Framework, along with its Generative AI Profile. At minimum, decide who approves AI output, which data the models may see and how decisions are logged.
Trying to modernize everything: focus on what matters
It is tempting to convert the whole estate at once. Resist it. A single, all-at-once migration concentrates every risk into one cutover. The business waits months or years before seeing any value, errors from hundreds of modules surface together and are hard to trace. And if something breaks on switch-over day, there’s no working system to fall back on.
Gartner’s research on mainframe migrations recommends deciding “workload-by-workload”: some are worth moving to a new platform, while others are better kept where they are and improved. We take the same idea one level further and modernize module by module, so each change can be tested and verified before the next one starts.
A limitation of our own approach
The incremental, test-first method we recommend has a real cost. Discovery and the test safety net take weeks before the first module moves, so stakeholders see less visible progress early on. It is also a poor fit if you need a single fixed price for a full rewrite on day one. We think the trade is worth it for business-critical systems, but it is a trade.
A short pilot on one module will tell you more about your real speed-up than any vendor slide. Abto Software has moved VB6, VBA and LISP products to .NET and modernized complex software for clients across industries. We can help you transform your legacy systems one verified step at a time. See our .NET modernization cases or book a call.
Conclusion
AI will not modernize your legacy system for you, but it can take over much of the slow, manual work that used to make modernization so painful. Projects that succeed use it first to understand and test, then move in small, verified steps with engineers in charge. Projects that fail tend to bet on a single automated leap.
If you want to know how AI can realistically speed up modernizing your own system, contact Abto Software for an expert assessment.
FAQ
Not reliably. It can produce a useful first draft, especially for VB6 and other mainstream languages, but complex logic, performance-sensitive code and data handling still need expert review.
Not without review. AI-generated code often looks production-ready when it isn’t. It can contain security flaws, misread business logic or quietly change how the system behaves.
That’s why AI-generated code can go to production safely only after the same checks as any other code: engineering review, automated security scanning and tests that confirm it behaves like the system it replaces. Treat it as a draft from a fast but unreliable contributor, not as finished work.
It depends on the system. AI speeds up discovery, documentation and testing the most. Code conversion gains less, because every change still needs review. Clean, well-tested code benefits more than tangled, undocumented code. A one-module pilot is the most reliable way to measure your own speed-up.
No. It changes their work. Engineers who know the old system become more valuable, because they validate model output and explain why the code behaves as it does. Most teams add AI skills to their software engineering practice rather than cut headcount.
Start with a module that has high business value, frequent changes and a contained blast radius. Avoid starting with the most critical component or the easiest throwaway one: you want a pilot that proves value without risking operations.
No. Recovering missing documentation is one of the things models do best. What you need is access to the code, some sample data and people who can confirm whether the recovered rules are correct.



