Our approach to legacy code translation

In practice, many translation efforts fail. The reason? Not because the code cannot be rewritten, but because system behavior changes in hard-to-detect ways.

The core challenge is not syntax compatibility. You need to preserve complex system behavior across complex project structures that operate continuously and at scale.

Legacy platforms typically process large volumes of heterogeneous data, apply thousands of business-logic rules, and rely on steps that are only partially documented. Some stages exist outside the main pipeline. Others apply only to specific data sources or formats. Translations that ignore these facts often result in systems that appear correct but behave differently.

Our approach to AI-assisted legacy code translation is therefore as follows:
We do not try to replicate system structure, we preserve observable system behavior via an agentic model.

Why legacy translation often becomes a dead end

Most failed translations do not break immediately. Systems continue running. Data keeps flowing. Only later do teams notice missing fields, widened schemas, reordered outputs, or downstream systems behaving in an unexpected way.

The reason is usually hidden logic. Over time, legacy systems accumulate behavior that is no longer visible in the main repository or described in documentation.

Automated translation tools, including those based on AI, typically operate on what is visible. Anything implicit, undocumented, or external to the main codebase will be dropped.

How we translate legacy code without losing behavior

Step 1: Recreate actual behavior before writing any code

Basic rule: Translation does not start with generation. It starts with investigation.

Work starts by establishing what the legacy system actually does in production. Source code alone is rarely sufficient. Logic is often fragmented across repositories, implemented in multiple languages, or triggered only under specific data conditions. We isolate a small number of critical workflows and analyze them using real input and output datasets. AI helps trace execution paths, explain transformations, and summarize behavior in a form that can be validated. The result is a concrete description of system behavior for each selected workflow, including edge cases and inconsistencies.

Step 2: Eliminate ambiguity

Once behavior is understood, the primary risk is allowing AI to infer missing structure. Open-ended prompts force models to guess execution order, phase boundaries, and data contracts. This produces fragile implementations and wastes tokens. To prevent this, we constrain the problem explicitly. Transformation stages are defined and separated. Inputs, outputs, schemas, and formats are fixed based on validated data. Scenarios that are not operationally relevant are excluded.

Practical example

In one of our projects, which performed ETL translation, a data flow initially appeared to be a simple transformation with two distinct phases, pre-import and import, which performed the main business logic. However, later analysis revealed that the logic actually consisted of three distinct phases for some dealers. The preprocessing step, which was preceding the two phases and reshaping raw input files (by joining, filtering, grouping and aggregating), was not initially provided by the customer. When the AI was asked to translate the flow without information from this step, it produced code that appeared to be correct but did not behave as expected, with missing data in the output. However, this step was obviously more complicated. To have better control over the automated code generation, we provided the AI not only with input and output files but also with some intermediate files for reference (between pre-processing and pre-import phases and between pre-import and import phases), as well as configuration files, format descriptions, column order, and nullability rules. Once these boundaries were established, the AI began producing consistent, testable translations with high accuracy.

Step 3: Reduce structural complexity before applying AI

Not all legacy complexity is semantic. Much of it is structural: duplicated scripts, copy-pasted files with minor variations, and orchestration logic scattered across batch or shell scripts.

Asking AI to reason over this directly produces noisy and inconsistent results. Instead, we apply deterministic techniques first: similarity analysis, file hashing, and grouping. Redundant variants are collapsed into canonical forms.
Only this reduced, representative logic is passed to AI. This shifts effort away from repetitive low-value manual work and toward high-value translation.

Step 4: Treat AI-generated code as a hypothesis

AI-generated code is never considered final. Each translation is treated as a hypothesis given these inputs this implementation should reproduce observed behavior.

We validate against real datasets, often at production scale, reviewing mismatches individually. Many discrepancies reveal historical bugs or undocumented quirks in the legacy system. At this stage, a human architect decides whether behavior should be preserved or corrected.
This is where responsibility remains firmly human.

Step 5: Use data-only reconstruction as a last resort

In rare cases, source code and specifications are unavailable. Only historical input and output data remain. In these situations, AI can assist in reconstructing transformation logic by iteratively refining candidate functions against large datasets. This approach can recover stable behavior quickly but carries greater risk. Legacy outputs may contain formatting artifacts, historical errors, or unintended side effects.

Human review is mandatory to determine which behavior reflects intent and which should not survive modernization.