Every large organisation ends up dependent on key digital systems to run their business. For off-the-shelf products you often end up dependent on their licensing and pricing arrangements. For custom solutions you often end up dependent on key people knowing the system, and assuming that regular maintenance and upgrades are getting prioritised.
But technology moves fast, people move on, and proactive maintenance often gets deprioritised. This is how business-critical systems become liabilities, while the cost of legacy system modernisation keeps the business case out of reach. Legacy system modernisation means updating, rebuilding or replacing ageing software so it is safer, easier to maintain and better suited to current business needs.
Even with all that risk, the business case to upgrade never stacked up. This was often because upgrading or refactoring these key digital systems was very expensive. It would take experienced software engineers a lot of time to implement and test, not to mention all the previously unknown integrations that get discovered along the way. The maths just did not work.
How AI Changed the Legacy Modernisation Business Case
We recently started a sizeable modernisation of a key customer-facing system for one of our government partners. We have been supporting their system for a couple of years now, after inheriting it from a previous vendor. But the frontend has always been a problem. It was originally built on a relatively niche frontend framework that quickly went out of long-term support.
We wanted to move away from this existing framework and towards the more stable React. Our government partner wanted the same. But unfortunately this required a significant amount of refactoring that came with a significant cost. A prohibitive cost, in this case.
But six months later that changed, all thanks to AI. In the time since the business case AI tooling had moved on so quickly that we wanted to revisit our previous estimates - how much of this could AI assist with?
We ran a proof of concept over the course of the day to help validate this question. We spent the day exploring how well an AI agent could generate the necessary baseline documentation and how effectively a separate AI agent could refactor the application based on this documentation.
We were pleasantly surprised! Based on our proof of concept we estimated the AI boost could save up to 40% off the estimated effort to carry out this refactor. And that tipped it over into a viable investment.
So where did this saving come from? And what did we do to make sure we safely harnessed AI agents to help with this work?
AI helps most where the knowledge is deepest
An AI coding agent is only as good as what it has been trained on, and the additional context available to it. Widely adopted programming languages and frameworks have a lot of publicly available documentation, blogs, tutorials, and other resources that the Large Language Models have been trained on. So React as a target client-side framework was a logical choice, both because it is more likely that AI agents implement it sensibly and our own people are much more familiar with it.
MadeCurious has long been a fan of boring, trusted technology. We have written extensively about the reasons why. This argument is now even stronger in the age of AI-assisted software engineering.
The second part of the equation is the domain and web application specific context that focuses the AI agents on what should be built, not just how it should be built. When we inherited this particular web application it came with very little supporting documentation from the previous vendor. We have been building out a documentation knowledge base over time, but it still lacked some foundational system behaviour. This is both a problem for AI agents and the people working on the system!
To help address this we started this refactor process by having an AI agent work backwards from the existing code and write up what it was actually meant to do. Our team, along with our partner's subject-matter expert, then went through it. Picking holes in a strong first draft is far quicker than starting from a blank page, and the agent got most of it right. This documentation helps new people on both sides get up to speed, and it gives our own AI agents the context they need to do the refactor well. Again, we have written more on our changing approach to documentation in this AI era, so check out this article for more information.
Making it safe to move fast
The extensive documentation generated was the first step of being able to safely start this client-side refactor. The second step was ensuring extensive test coverage to quickly catch any regressions introduced by these deep changes.
The system had arrived with far less automated test coverage than we would ever build ourselves on a new application. And while we had been adding to it over time, it was still short of our quality standards. A good test suite has always been a foundation of good software engineering. But it is a non-negotiable for fast, safe AI-assisted engineering.
We built a rigorous automated test suite based on the documented behaviour. Again, AI is very good at recommending test cases - so developing this test suite was far quicker than it may have been 6-12 months earlier. This test suite has not only lifted the system to meet our production-ready standards, but it keeps paying off well beyond this refactor because it reduces the manual regression testing our partner would otherwise perform on every future change.
A human is always in the loop
For all the efficiency AI has brought to this work, none of it happens on autopilot. A core principle of how we adopt AI at MadeCurious is that a human is always in the loop. We are not handing a refactor like this over to a swarm of agents and walking away - our engineers are reviewing and steering the work at every step.
AI agents are eager to generate lots of code - often reinventing a function here, or rebuilding a component that already exists somewhere else in the codebase. If left unchecked this is exactly how we accumulate the kind of inconsistency and technical debt we are working to move away from. So we are constantly reining it in, pointing agents back to what has already been built and holding the line on our engineering standards.
This is where the documentation, the test suite, and strong observability all come together. They are the guardrails that let our people move quickly with AI without moving carelessly, and they are fundamental to how we operate as an AI-native organisation. We are moving far faster than we could have previously done, but this still requires experienced software engineers to safely achieve the 40% efficiency gains seen on this particular refactor work.
Why Legacy Modernisation Projects Are Worth Reassessing
We are now over a month into this refactor and so far we are continuing to track to the 40% efficiency gain we had initially estimated. The first key module of the application is close to going live in React. There is still work to be done, but the maths is holding up.
We are not the only ones seeing this shift, and it is not limited to the size of job we took on. Recently Anthropic engineer Jarred Sumner described the experience of rewriting Bun, a widely used Javascript runtime, from Zig to Rust. By his own estimate this was a job that would have taken three experienced engineers about a year to do by hand. It was achieved in eleven days, with the heavy use of AI agents. That was more than half a million lines of code!
Now not every organisation has the experience (or the available token expenditure) to achieve this sort of feat. But there are still real gains to be made when it comes to modernising your aging application.
Addressing the risks in your key digital systems has never been easy, but the path to modernisation is now far cheaper than may have been quoted even a year ago. At the same time AI agents are starting to surface risks we could not see before - flagging security vulnerabilities that have sat unnoticed in legacy code for years. So it is definitely worth revisiting those legacy system modernisation business cases that did not stack up previously.
If you have a business-critical legacy system you are looking to modernise, we would be glad to talk through whether the maths has changed for you too.
"Tackling this kind of work alongside AI has brought real benefits - some we expected, plenty we didn't. We're moving far faster than we could have before, but just as importantly, we're raising the bar on quality. That gives us the confidence to build on solid foundations and keep moving efficiently. We're also deepening our understanding of a system we inherited, and capturing it as documentation and context that both people and agents can draw on well into the future."
- Julia T. (Software Engineer at MadeCurious)
FAQ on Legacy System Modernisation in the AI Era
What is legacy system modernisation?
Legacy system modernisation is the process of updating ageing software, infrastructure or code so it is more secure, maintainable and suitable for current business needs. It may involve refactoring an existing system, replacing parts of it or moving it to a newer framework.
Is it cheaper to modernise a legacy system with AI?
Often, yes. On a recent frontend modernisation we estimated the work would cost around 40% less with AI agents assisting our engineers than it would have by hand. It will not make every project viable.
Which legacy systems are the best candidates for AI-assisted modernisation?
The biggest wins come when you are moving towards a mainstream, well-documented technology. AI coding agents are strongest with widely adopted languages and frameworks, like React or Python, because there is a deep public record of how they are used for the models to draw on. Migrating away from a niche or end-of-life framework, and towards a popular and stable one, is where AI assistance goes furthest. Systems with reasonable existing documentation and test coverage give agents more to work with too - though both can be rebuilt with AI as a first step.
Is it safe to let AI coding agents work on a business-critical or sensitive codebase?
It can be, provided the right guardrails are in place. We do not provide AI agents access to credentials or configuration files, personal or financial information, or partner data without explicit permission. We keep a human in the loop at every step, work against thorough documentation and an automated test suite that catches regressions, and rely on strong observability to see how the system behaves.
How do you stop AI from introducing bugs or duplicating existing code?
This is where human oversight matters most. Left unchecked, agents tend to generate more code than needed, rebuilding functions or components that already exist. Our engineers review and steer the work, pointing agents back to what has already been built, while the documentation and test suite catch regressions before they reach production. There is a real efficiency gain, but it is one we still need to actively manage.
