Migrating a legacy system isn’t simply a matter of replacing words from one programming language with others. Mistral worked with a European energy company to move 40,000 lines of Fortran 77 to C++, a process that shows how AI agents can help rescue scientific software that is difficult to maintain.
The code belonged to a reservoir simulator used for physical calculations. It had decades of history, no test suite, and much of its knowledge was scattered across comments, PDF documents, and the experience of specialized engineers.
The challenge wasn’t translation, but modernization
Fortran 77 was standardized in 1977 and reflects the limitations of that era. The language had no modules or namespaces like those commonly used today. It also relied on COMMON blocks, a way to share global memory between different parts of a program.
It also allowed variables to be typed implicitly based on their first letter. A typo could silently create a new variable instead of stopping compilation. Names, on top of that, were limited to six characters, making it harder to understand the original intent of the code.
Converting that system to C++ required architectural decisions. Global data had to be transformed into clear structures, types had to be declared explicitly, and some control flows based on GOTO could be reorganized into loops and returns that were easier to maintain.
Translating code can produce a program that works. Modernizing it means making it understandable, testable, and ready to evolve.
The parity test came first
Before allowing the agents to modify the code, the team built a mechanism to demonstrate that the new version produced the same results as the original.
The strategy involved comparing both the final results and important intermediate values, selected together with the reservoir engineers. To do this, the team:
- Added subroutines to the Fortran code to export the program’s state.
- Created a C++ testing framework capable of loading those checkpoints.
- Prepared
Skill.mdfiles to guide the agents on how to use the tools correctly.
For example, the original code could save the value of a variable such as RHOG during a run. The C++ version had to produce that same value at the equivalent point. This allowed the team to verify the migration using concrete data, not just a visual review of the code.
This step also reduced the risk associated with the agents’ long-running executions. If a modification broke numerical equivalence, the tests could detect it quickly.
AI agents to recover lost knowledge
The documentation wasn’t organized alongside the code. Some of it was in old documents, while other parts were hidden in comments. To address this, Mistral generated a relationship tree between procedures, showing which parts of the program called others.
Using that map, it deployed more than one hundred agents through Vibe CLI to document the system. Each agent could consult the relevant PDFs using document libraries and Mistral OCR, the company’s optical character recognition tool.
The work progressed from the smallest parts of the program upward. Each agent documented one node in the tree and opened a change request in the original repository. Another agent periodically reviewed those requests and asked for corrections when necessary.
The result wasn’t just a partially migrated codebase. It also created an explanation that was closer to the code—something essential when the original authors are no longer part of the team.
Full autonomy wasn’t enough
In the first attempt, Mistral assigned one agent to each subroutine and allowed it to translate independently for a week. The resulting program worked, but it retained too many characteristics of the original design.
The COMMON blocks became nearly identical global structures. The control flow based on GOTO remained largely unchanged. Instead of modern C++, the result looked like Fortran written with different syntax.
In the second attempt, the team organized several roles for each module: a planning agent, a programming agent, a testing agent, and one dedicated to code quality. The structure improved significantly, although the agents could become stuck after several attempts to fix a complex error.
The final solution combined autonomy with human oversight. One professional coordinated a workflow made up of programming, testing, and review agents. When the system encountered a difficult problem, a person stepped in to unblock the process.
A module-based workflow
With the documentation and tests ready, the team divided the code into independent modules. Each module was a subtree of the system and, based on the project’s experience, needed to contain fewer than about 10,000 lines of Fortran to remain manageable.
The process followed these steps:
- Design the equivalent architecture in C++.
- Review it with an engineer specialized in reservoirs.
- Turn the approved architecture into a task list.
- Run planning, implementation, and testing cycles.
- Review change requests before incorporating them into the repository.
- Repeat the process until the code was acceptable and the results were numerically equivalent.
This approach allowed the agents to work toward concrete objectives instead of confronting the entire legacy system all at once.
Three lessons for any legacy system
The first sprint covered 40,000 of the 300,000 total lines of Fortran code. The project started from a favorable position: the program was self-contained and could run. Other systems, especially those that depend on external services or contain scientific knowledge that was never documented, may require much more work.
Mistral’s experience offers three practical ideas:
- Build parity tests before migrating. Being able to demonstrate that the new version matches the old one provides a clear signal of progress.
- Organize the documentation first. An agent can process a lot of code, but it can’t safely interpret a system that nobody understands.
- Combine agents with human reviews. Full autonomy can produce functional but insufficiently modern results, while doing everything manually doesn’t scale well.
Artificial intelligence didn’t eliminate the project’s complexity. What it did was help divide, document, and verify it. That difference matters: in critical systems, AI doesn’t replace expert judgment—it allows that judgment to be applied to more parts of the problem.