The big-bang rewrite is back on the table. AI can analyze and transform codebases at a scale that used to require large teams. But success depends on what happens after generation: validation, comparison and controlled cutover.
For decades, the big-bang rewrite was enterprise technology’s forbidden move.
The idea was simple: replace an aging system with a clean modern stack. In practice it was slow, expensive and risky, often uncovering hidden business rules too late. So the default advice became the one you have probably heard from every advisor you have asked: don’t rewrite everything at once.
AI is now challenging that assumption. Modern coding agents can:
- explore repositories and dependencies;
- understand and explain legacy code;
- generate new implementations;
- create tests and documentation;
- fix compiler and test failures;
- scale changes across thousands of files.
Work that once required a large team can now be done by a smaller one.
The big-bang rewrite is becoming feasible again. But feasible is not the same as safe. AI can generate a replacement system at scale; it cannot prove that the replacement preserves the behavior your business depends on.
AI has changed the economics of rewriting
The first generation of AI coding tools completed functions and generated boilerplate. The emerging generation supports workflows that combine repository analysis, code generation, compilation, testing, automated repair and access to organization-specific APIs.
Google has published a case study of an LLM-assisted workflow applied across 39 internal code migrations. The model generated 74 percent of the code changes that were ultimately submitted, and the developers involved estimated that the tooling cut total migration effort by roughly half.
This was not an autonomous rewrite of an enterprise platform. But it showed that AI can operate inside a repeatable migration pipeline at substantial scale.
LegacyTranslate, a multi-agent system, is a second example. It was built to translate roughly 2.5 million lines of PL/SQL into Java, using separate agents to generate code, align it with internal APIs and refine it against compiler and test feedback.
These examples move the discussion beyond translating isolated functions. With the right context and engineering infrastructure, AI can take on a meaningful share of large-scale code transformation.
It can make the rewrite possible. What it cannot do automatically is make the rewrite equivalent.
A rewrite is not yet a migration
A repository is only one representation of a working system. The real business contract is also encoded in:
- years of accumulated database state;
- configuration and environment settings;
- batch schedules and processing order;
- external integrations and message queues;
- retry and recovery mechanisms;
- operational knowledge held by a few specialists;
- exceptions added for particular customers or markets.
Some of this behavior is intentional. Some is accidental. Some is a defect that other systems now depend on.
An AI agent can read the implementation. It cannot decide which of those behaviors you have to preserve, which you should correct and which you can safely remove.
That is not an engineering decision. It belongs to the people who know why an exception was added for one market in 2014, or which reconciliation report the finance team actually relies on at close. AI compresses the work of developers. It does not compress the work of the specialists and process owners who have to adjudicate every difference—and on most projects that group is small, busy and already fully committed elsewhere. On a large migration their availability sets the pace more often than the speed of code generation does.
That distinction shapes the whole project. In a like-for-like modernization, the goal is to preserve business behavior while changing the technology underneath it, so an unexplained difference is probably a defect. In a product redesign, some behaviors are changed deliberately but those changes still have to be identified and approved, or you lose the ability to tell an improvement from a regression.
A useful rule: Every difference remains a potential defect until someone can explain why it is acceptable.
Read more on custom software development
Legacy modernization with AI starts as archaeology
AI agent development is changing the economics of custom software
AI legacy code modernization: from untouchable systems to understandable software
Vibe coding: a fast track from idea to application, or a risky shortcut?
Generative AI in pharma: A virtual assistant for smart sales
8 generative AI trends to watch in 2025
Ten business use cases for generative AI virtual assistants
A web application security checklist for every stage of development
Time and material vs. fixed-price contracts: Is there a smarter alternative?
Code can look right and still behave differently
A generated replacement may compile, pass static analysis, follow the target architecture and look clean in code review. Its unit tests may all be green. Those signals matter. None of them proves that the system preserves its predecessor’s behavior.
Research into LLM-translated scientific code illustrates the risk. Kaizen, a framework for validating LLM code translation, examined programs translated from CUDA to OpenMP. Some compiled and passed their existing tests, then produced incorrect results on other inputs.
That research concerns scientific computing, so the findings are not a general failure rate for enterprise software. But the mechanism transfers: shallow checks miss semantic errors that surface only under particular conditions.
The same pattern appears in business systems. A replacement might:
- process a standard invoice correctly but mishandle a correction from an earlier period;
- return the right API response while writing a different database status;
- calculate the right total but emit events in the wrong order;
- work normally but create duplicates after a timeout and retry.
A green build proves that the program can run. It does not prove that it can safely take over the business process.
Validation is the real migration capability
When implementation gets faster, validation becomes the center of gravity.
Validation does not mean a mathematical proof of complete equivalence. For most enterprise systems that would be unrealistic. It means building reproducible evidence that the old and new systems produce equivalent material outcomes under the conditions that matter. That evidence is assembled in layers.
- Build and structural validation. The replacement should compile, follow architectural standards, use approved dependencies and pass security and static-analysis checks. These are necessary conditions, not final proof.
- Characterization tests. Legacy systems often have incomplete documentation and weak test coverage. In those cases the system itself provides the baseline. You run selected inputs through it and record responses and calculations, errors, database changes, generated documents, emitted messages and audit entries. Those recorded results become regression tests—golden masters the replacement has to reproduce.
- Differential testing. The same inputs go to both systems and their outcomes are compared. The word “outcomes” is doing real work here: comparing API responses is rarely enough. A meaningful comparison covers database state, balances, events, documents, errors and downstream side effects. Results do not always need to be byte-for-byte identical, because field order, formatting or timestamp precision can differ without changing business meaning. The comparator has to distinguish an irrelevant difference from a broken rule.
- Broader input exploration. Known examples are not enough. Test boundary cases, production-derived datasets and unusual data combinations. Property-based testing and fuzzing reveal differences the original regression suite never covered. In regulated environments, production data has to be masked or synthesized before it can be used this way, and doing that without destroying the edge cases you were trying to test is a design task in its own right—not a preprocessing step.
- Data reconciliation. For stateful systems, the question is whether both versions arrive at the same meaningful business state. That means comparing balances, totals, statuses, record counts, allocations and downstream events.
- Difference management. Every mismatch has to be investigated. It may be a defect in the new implementation, a problem in the comparison logic, an irrelevant technical difference, an undocumented legacy behavior, an intentional product change, or a legacy defect you have chosen to correct.
The output is more than a test report. It is the evidefnce on which you can base a decision to retire the old system.
The effort moves; it does not disappear
None of this is free, and it is worth being explicit about what it does to a business case.
AI compresses the generation phase. It does not compress validation to the same degree, because validation effort scales with the number of business processes, their criticality and the quality of the evidence already available—not with lines of code. A codebase that is 60 percent boilerplate can be transformed quickly. The settlement logic buried in the rest still has to be proven process by process.
So the shape of the project changes. Generation moves from the largest cost line to a moderate one. Comparison, reconciliation and difference management become the largest. Total effort can still fall, but rarely in proportion to the share of code an agent produced. A figure like “74 percent of changes generated” describes one phase of a migration, not the migration.
The compensation is that validation work is not disposable. The characterization tests, the comparison harness and the reconciliation queries all outlive the project. They become the regression suite for a system that never had one—which is often the more durable outcome, because the reason the legacy system became untouchable in the first place was that nobody could prove what a change would break.
Production is the final test environment
No test environment fully replicates production.
That is why high-risk migrations use shadow execution or dual run: both systems process real workloads while the legacy system remains authoritative, which allows comparison under real conditions.
Google Cloud’s Dual Run, for example, compares modernized mainframe systems with their legacy versions before go-live, checking correctness, completeness and performance. This requires strict controls to prevent duplicate actions such as double charging or duplicate messages, and it may involve data masking or controlled replay.
Shadow running also consumes calendar time that fast code generation cannot win back. Some behavior only appears on a business cycle: month-end close, quarterly reporting, annual renewals, seasonal peaks. If a process runs twelve times a year, one validation cycle takes a month—however quickly the replacement was written. Cutover dates should be set from the business calendar, not from the engineering estimate.
Once confidence is sufficient, responsibility is transferred gradually using feature flags, canary releases, staged routing or module-by-module rollout. Rollback must be tested, not assumed. The rewrite can be large but risk transfer should be incremental.
Measure evidence, not generated code
The percentage of files translated is an attractive progress metric. So are lines of code generated, compilation rates and passing unit tests.
None of them answers the question you ultimately have to answer:
Can we safely switch off the old system?
Better indicators include:
- critical processes covered by comparison;
- representative transactions validated;
- unresolved mismatches;
- data-reconciliation results;
- production traffic verified;
- rollback readiness;
- legacy components safely retired.
So the most useful question to put to a modernization provider is not how quickly can AI rewrite our codebase?
It is: how will you demonstrate that the replacement preserves the outcomes our business depends on?
The real test of modernization
AI can make legacy modernization faster. But speed is not the measure of success. The real test is whether you have enough evidence to trust the new system with the business processes that matter—and, ultimately, to switch the old one off. That requires engineering discipline, rigorous validation and human judgment alongside AI.
If you are exploring AI-assisted legacy modernization, drop us a line at sales@fabrity.pl.
