The software isn’t always the problem. Why rewriting code isn’t the only path to modernization


Published 24/06/2026 By nAG

REAL CUSTOMER INSIGHT

Organisations want to continue benefiting from the software they trust, but they need that software to fit naturally into the environments where work now takes place.”

When organisations talk about modernization, the conversation often starts with replacement. Legacy systems are viewed as something to migrate away from, rebuild, or eventually retire. The assumption is that progress requires moving on from the software that has been in place for years, sometimes decades.

Yet many of the organisations we speak to are finding themselves in a more nuanced position. The numerical software at the heart of their operations is often not the problem. In fact, these codes frequently represent years of development, validation, and domain expertise. They continue to produce trusted results and support critical business processes. What has changed is the environment around them.

Asking a different modernization question

Through our work supporting customers whether researchers or developers in national laboratories, we have encountered a remarkably consistent challenge. Organisations want to continue benefiting from the software they trust, but they need that software to fit naturally into the environments where work now takes place.

Modern interfaces, trusted numerical kernels

One recent pilot project has provided an excellent illustration of this challenge. Working with a chemical process simulation application developed in Fortran, our objective was not to rewrite the numerical routines or alter the algorithms themselves. Instead, we focused on creating modern interfaces around the existing code. This included generating Python wrappers, producing documentation automatically, developing a simple graphical user interface, and enabling the same routines to be accessed directly from Excel.

The numerical core remained unchanged, but the ways in which users could interact with it expanded significantly.

Graphic depicts background, steps taken, and outcomes of a recent client project to modernize code without rewriting

What makes this approach interesting is that it demonstrates an alternative view of modernization. For many organisations, modernization has become almost synonymous with migration. Yet there are situations where the greatest value can be delivered not by replacing proven software, but by making it more accessible.

A trusted numerical kernel that can only be accessed by a small number of specialists may struggle to survive in the long term. The same numerical kernel, exposed through modern languages, supported by clear documentation, and integrated into familiar tools, can continue delivering value to a much broader audience.

What we’re hearing from the community

We have also seen this reflected in the conversations generated by our recent blogs. Readers have reached out to discuss wrapper generation, language interoperability, and ways of making existing Fortran, C, and C++ libraries easier to use within contemporary software environments.

These discussions reinforce a belief that there is a substantial community of scientists and engineers facing similar challenges. Many are not looking for complete rewrites. They are looking for practical ways to bridge the gap between proven numerical software and modern methods of working.

The same challenges are appearing everywhere

The same pattern has emerged through our outreach to research institutions and national laboratories. Demonstrations showing how established numerical libraries can be exposed through C, C++, C#, and Python interfaces have generated interest not because they introduce new algorithms, but because they make existing algorithms more accessible.

Automated documentation, multilingual support, and reproducible distribution pipelines are increasingly recognised as key drivers of scientific productivity.

What is particularly striking is the consistency of the message. Whether the organisation is commercial, academic, or government-funded, the underlying challenge is often the same: how to continue extracting value from trusted numerical software while enabling it to participate in modern workflows.

Modernization is not a single path

None of this suggests that modernization programmes are unnecessary. There are many situations where replacement, redesign, or migration will remain the right strategic choice.

However, our experience increasingly suggests that modernization is not a single path. Between maintaining a system exactly as it is and undertaking a full rewrite lies a wide range of opportunities to improve usability, accessibility, maintainability, and adoption.

Building a bridge between past investment and future innovation

This perspective is shaping the direction of a new support service. We are increasingly viewing the initiative not simply as a way of supporting legacy software, but as a bridge between trusted numerical code and modern computing environments.

Whether that means Python, Excel, Jupyter, C#, graphical interfaces, or technologies that have yet to emerge, the underlying objective remains the same: helping organisations continue to benefit from the software they trust while giving users the experience they increasingly expect.

Perhaps the most important lesson from the work so far is that modernization should not always begin with the question, “What do we need to replace?”

In many cases, a more productive starting point is, “How can we make what already works easier to use?”

The answer to that question may reveal opportunities that are faster, less risky, and more valuable than organisations initially expect.

Keen to learn more? Think you’d benefit from a software assessment? Schedule a call with the team.