Fortran

The Reality

Fortran is not a relic. It is still the fastest option for numerical computation in many domains, and for good reason. Decades of optimisation by compiler vendors mean that well-written Fortran code for matrix operations, fluid dynamics simulations, or Monte Carlo modelling will outperform equivalent code in most newer languages. The scientific and engineering communities know this, which is why Fortran 2018 exists and why new standards continue to be developed.

The problems are rarely about the language’s computational ability. What surrounds the code is where things become difficult. The engineers who wrote the original codebase have retired or moved on. The build systems rely on toolchains that assume a specific Unix environment from fifteen years ago. The code works brilliantly in isolation but has no way to talk to the web services, dashboards, or data pipelines that the rest of the business now depends on. And when a Fortran routine is embedded inside a larger system (a pricing engine, a risk model, a simulation pipeline) the integration seams are where things break.

The Risks of Doing Nothing

• Talent attrition without knowledge transfer. The people who understand your Fortran codebase are a shrinking group. Every departure without documentation makes the system harder to maintain.
• Integration debt compounds. As the rest of your infrastructure modernises, the gap between your Fortran components and everything else widens. Manual data transfers, file-based integrations, and batch-only workflows become bottlenecks.
• Compiler and platform lock-in. Older Fortran code may depend on compiler extensions or platform-specific behaviour that limits where and how it can run. Moving to newer hardware or cloud infrastructure becomes a blocked path.

How We Approach This

We do not recommend rewriting working Fortran computation in another language. That is expensive, error-prone, and the result is slower. Instead, we focus on wrapping and connecting.

The most common pattern we use is building a service layer around existing Fortran code. This might mean compiling Fortran routines into shared libraries and calling them from Python or C via foreign function interfaces, or containerising the Fortran runtime so it can be deployed and scaled independently. The computation stays in Fortran. The integration happens in a language better suited to it.

For organisations where the build and deployment process has calcified, we start there. Moving from a manual compilation workflow to a reproducible build pipeline (with version control, automated testing of numerical outputs against known benchmarks, and proper dependency management) reduces risk before any functional changes are made. Once the build is trustworthy, integration work can proceed with confidence.

What You End Up With

• Fortran computation preserved, with its performance characteristics intact
• Modern API or service wrapper enabling integration with web applications and data pipelines
• Reproducible build and deployment pipeline replacing manual processes
• Documentation of the codebase sufficient for future maintenance
• Reduced dependency on any single individual’s knowledge

What We Have Seen

We worked with a firm whose pricing engine relied on Fortran routines originally written in the early 2000s. The code was sound, validated against known outputs over years of production use, but it could only run on a specific server because the build process was undocumented and depended on a particular compiler version. We containerised the runtime, wrapped the key routines with a Python service layer, and connected it to their internal API gateway. The Fortran code was unchanged. The firm gained the ability to call their pricing engine from any internal system and to deploy it on new infrastructure without a manual rebuild.

How Much Time Have You Actually Got?

Fortran is the legacy language least likely to be your actual problem. It is still actively maintained, still compiled by current toolchains, and still the fastest sensible option for a lot of numerical work. If somebody has told you Fortran is the risk, they are probably wrong.

The risk is almost always one of three things around it.

You have years, not months, if: it compiles with a current compiler, the build is scripted, and someone can explain what the numbers mean.

You are inside two years if: the build depends on a specific old compiler version or a machine nobody wants to touch. When the build environment is the fragile part, the code’s quality is irrelevant.

You are inside twelve months if: one person validates the output. Numerical code has a particular failure mode: it keeps producing plausible numbers after it starts being wrong. If only one person can tell correct from plausible, that is the exposure, and it is a knowledge problem rather than a language one.

You have a hard deadline if: the results feed a regulated or audited process and you cannot demonstrate how they are produced. Auditors increasingly want provenance, not just output.

What Breaks First

1. The build environment: a specific compiler, specific flags, a specific machine.
2. Validation knowledge, when the person who could sanity-check results leaves.
3. Input and output formats, as the systems either side modernise and expect something other than fixed-width files.
4. Hardware and OS, particularly for anything expecting a specific architecture.
5. The Fortran, essentially last. Well-written numerical Fortran outlives almost everything around it.

Check These Six Things This Week

• Can you rebuild it from source today, on a machine that is not the original one?
• Is the build scripted, or does it live in somebody’s head and shell history?
• Are there test cases with known-correct answers? If not, that is the first thing to create, ahead of any modernisation.
• Who can tell whether a result is right? Name them. If it is one person, plan around that.
• What formats does it read and write, and are the systems on either side changing?
• Is the source in version control? Numerical code is frequently the last thing to get there.

When You Genuinely Don’t Need To Act

Working Fortran, with a scripted build, a test suite, and more than one person who understands the domain, needs nothing. Rewriting it in a fashionable language will cost a great deal, take longer than anyone predicts, and quite possibly produce slower and less accurate results.

The work worth doing here is almost never a rewrite. It is capturing the build, the tests, and the knowledge, so the code stops depending on one person and one machine.

Already Thinking About Your Fortran Systems

Deciding what to do with Fortran code that works but does not connect is a genuinely difficult problem. Rewriting feels wasteful. Leaving it alone means the isolation compounds. There is a middle path, and it starts with understanding exactly what you have and where the integration pressure is highest. Get in touch and we will work through it with you.

For the broader integration picture, Legacy API Bridges and Connecting Old Systems to Modern APIs cover the middleware patterns we use when connecting isolated systems to modern platforms. If there is a database migration involved in moving data in or out of the Fortran pipeline, that page covers how we approach it. The Legacy Systems Overview provides context on how all of this fits together.