Generative AI vs. deterministic migration: what AI can do in your legacy system and what it can't

Over the past two years, the question a CTO most often asks us before starting a modernization project is always the same: 

«can't we just use AI to migrate the code?»

It's a legitimate question.

The case for generative AI: fast, cheap, and surprisingly capable in simple modules

Let's start with what generative AI does well, because ignoring it would be dishonest. A modern LLM can take a 200-line VB6 module, understand its logic, and produce a Java or C# equivalent in a matter of seconds. For low-complexity modules (data entry forms, query screens, basic reporting logic) the quality of the generated code can be surprisingly good.

The speed is real. A developer who takes two weeks to manually rewrite 50 screens can cut that time down to days with AI assistance. For low-criticality internal applications, this may be enough.

The problem isn't that AI is bad at generating code. The problem is what happens when the system has 20 or 30 years of accumulated history and the business logic isn't in the visible code but in conventions, workarounds, and patches that no one ever documented.

Where generative AI falls short: the determinism problem in critical systems

The technical term is non-determinism. Given the same source code as input, an LLM can produce different outputs across different runs. Not always. Not necessarily in simple modules. But the possibility exists, and in mission-critical systems, that possibility is not tolerable.

Consider an insurance company's premium calculation system or a bank's settlement engine. A variation of 0.01 in a risk coefficient isn't an interface bug the user reports — it's a regulatory discrepancy that the auditor identifies. And when the CTO has to explain to the regulator why the calculation logic has changed, "the model generated it that way" is not a valid answer.

In the projects we've analyzed, the pattern is consistent: teams achieve promising results in the simplest modules and get stuck on the most critical ones. The underlying problem isn't speed — it's certainty. The most common symptoms we've observed are:

• Real coverage of 60-70% of the code, with blockages in the most complex modules.
• Inconsistencies in handling edge cases that the original code managed correctly and the generated code failed to replicate.
• Inability to formally demonstrate 100% functional equivalence, which blocked audit approval in regulated environments.
• Dependence on exhaustive manual review that eliminated the initial speed advantage.
• The30-40% of code that AI doesn't cleanly cover is, almost always, the most critical 30-40% of the system.
•  

What deterministic migration is and why it matters in regulated environments

An automated deterministic migration process applies formal transformation rules to the source code: given the same input, it always produces the same output. There is no statistical variability. There is no interpretation. The code is transformed following a set of rules specifically designed to preserve the semantics of the source language in the target language.

The practical difference is traceability. In a deterministic process, any line of the target code can be traced back to its exact equivalent in the source code. This isn't just a technical advantage: it's the answer to the regulator. When the auditor asks "how do you guarantee that the calculation logic is identical to the original?", line-by-line traceability is the only answer that closes the argument.

Go4IT Solutions' proprietary pivot language acts as an intermediate layer between the source language (VB6, COBOL, RPG, Oracle Forms) and the target language (Java, Angular, .NET, Spring Boot). This intermediate layer is what makes the transformation reproducible, auditable, and completely independent of the chosen target language.

Where generative AI does add value within a modernization project

The argument isn't that generative AI has no place in a modernization project. It does. Just not at the core of critical code transformation.

The three phases where AI adds real value are:

• Initial assessment. Automatically cataloging the code inventory: number of modules, dependencies between components, cyclomatic complexity, technologies used. A process that would take weeks manually can be significantly accelerated with AI.
• Technical documentation generation. Most legacy systems that are 20-30 years old have little to no up-to-date documentation. LLMs can generate functional documentation of the original system that serves as a foundation for designing the target architecture.
• Validation test generation. Once the system is migrated, AI can generate test batteries that verify the target system's functional behavior is equivalent to the original. This significantly speeds up the validation phase without compromising the certainty of the result.

Go4IT Solutions' position isn't "AI bad, determinism good." It's more precise than that: AI where it adds value, determinism where certainty is mandatory.

Comparison table: generative AI vs. deterministic migration for legacy systems

Questions about generative AI and legacy system migration: what models can really do and what they can't

Partially. It works well on simple modules, but it doesn't produce deterministic results: the same source code can generate different outputs across different runs. In critical systems — such as bank settlements or policy calculations — that variability is not acceptable.

Deterministic migration applies formal rules: the same input always produces the same output, and functional equivalence is verifiable line by line. Generative AI produces probable results, not guaranteed ones. Only the former approach lets you demonstrate to an auditor that business logic has been fully preserved.

Because a system that's 20-30 years old has business logic buried in conventions, patches, and workarounds that no LLM can infer with certainty. Blockages consistently appear in the most critical modules — exactly the ones that can't be left half-done.

In the initial assessment (cataloging code and dependencies), in generating technical documentation of the original system, and in creating validation tests. Where it should NOT be is at the core of critical code transformation.

It's a process that transforms code following formal rules: given the same source code, it always produces the same target code. The result is auditable and traceable, which in regulated environments (banking under DORA, insurance) isn't an advantage — it's a requirement.

In the projects we've analyzed, blockages always appear in the most complex modules: edge cases, rules accumulated through patches, and conventions specific to the system. These are precisely the modules that concentrate the most critical business logic.

If the system processes financial transactions, calculates premiums, or is subject to regulatory audits, it needs a deterministic process. If it's a low-criticality internal tool, AI may be viable. The fastest way to find out is a proof of concept on the system's actual modules.