Legacy systems consume more than 50% of IT budgets, whether through upgrading to more current versions or through the inefficiencies they impose on productivity. AI is here to help reduce legacy systems and prevent them from emerging in the future. In this article, we share our approach at Hi Interactive.
What “legacy” means and how AI can avoid it
The term legacy in software development may seem straightforward at first glance, but even with two decades of experience in this field, I had a very simplistic and mistaken understanding of what it actually meant, reducing legacy to little more than outdated software that generates inefficiency. The truth, however, is that it is not quite that simple.
Legacy software is not simply old software. A system becomes legacy when the cost of maintaining it begins to outweigh the value it delivers: when every small change requires disproportionate effort, when the people who truly understand it are retiring or leaving, and when the business finds itself adapting its processes to fit the software, rather than the other way around.
It is, in essence, a debt. Not technical debt in the abstract sense, but a very real organisational burden: slower time-to-market, higher operational risk, mounting dependency on scarce expertise, and an ever-growing gap between what the system does and what the business actually needs.
The irony is that most legacy systems were once considered modern. They were built with the best tools and intentions of their time. Legacy is not a flaw in origin; it is an inevitable consequence of time, growth, and change.
Reusing code libraries where only 10% of their resources are truly used
Until not long ago, reusing code libraries and adopting low-code or even no-code approaches were the main strategies for reducing costs, accelerating development, and meeting time-to-market demands. But they brought with them what we now call legacy.
When a team reuses a library where only 10% of its resources are truly needed, it is nonetheless forced to maintain 100% of it. This creates hidden overhead costs that only become visible once the solution is already in production.
Using AI to reduce unused code
AI has made it possible to reduce dependency on pre-built code and ensure we only maintain what we actually use. Reducing the number of assets, components, and algorithms is today the guiding principle of any software project. The expression “less is more” has never made more sense than when applied to the future of software development.
How we reduce unused code dependencies
AI is changing the way we build software, enabling more custom code and reducing reliance on external pre-built solutions such as low-code platforms, no-code tools, and third-party libraries.
At the start of each project, we begin with zero dependencies, building from scratch as much as possible and evaluating each feature individually before deciding to adopt pre-built code. This evaluation should consider a few key questions:
- Building from scratch: Will it take significantly more time? How do we ensure security and long-term maintainability?
- Reusing pre-built code: What will the maintenance cost be over time? If it is community code, who guarantees it is kept updated, and with what regularity?
When building software, development time is not the only cost; it is simply the first one. Over time, maintenance costs grow and, if left unmanaged, can quietly threaten your business. These are typically hidden costs that must be factored in from the very beginning.
When to choose open source or closed-source
Choose closed-source
One way to gain stronger guarantees around process and security is to adopt closed-source platforms. While these are typically less flexible and more constrained, limiting deep customisation and preventing the use of custom AI agents to assist development, they can still meet the intended requirements and should not be dismissed outright. These platforms abstract away complexity, reduce the need for specialist expertise, and offer a level of security that open-source alternatives often cannot match.
They are a strong option for requirements that are less customised or complex, allowing teams to reach their goal without the overhead of building and maintaining everything from scratch.
That said, adopting this type of solution is also one of the main sources of legacy in the development ecosystem: they cannot be upgraded on your own terms, and in most cases only a fraction of their features are ever used.
Choose open source
Until very recently, open source was not a viable choice for many projects, primarily due to the implementation costs associated with the need for specialised skills and the pace of development required. The safer path was almost always to adopt pre-built platforms, frameworks, or libraries.
With the rise of AI-assisted coding, open source has become a serious option worth considering. The main barrier to adoption has been significantly reduced: less time, fewer specialised skills required, and lower risk.
This shift makes open source particularly advantageous when thinking about legacy reduction. Unlike pre-packaged solutions, open source allows a project to use only what it truly needs, without carrying unnecessary dependencies that, over time, become a source of legacy in their own right.
Legacy is something that will always exist and must be factored into the planning of any project or feature. But AI empowers us to reduce the technical debt that places so many constraints on businesses over the long term. If building from scratch was once almost always a mistake, too expensive, too slow, too risky, that rule no longer holds. In most cases, it is now the right decision.
The great irony of legacy: Frontend vs. Backend
The frontend ages quickly but is relatively easy to replace. Backend ages more slowly, yet is far harder and riskier to modernise; it is where decades of critical business logic quietly accumulate.
In theory, the frontend should concentrate the bulk of legacy code, precisely because it ages faster. In practice, however, the opposite tends to be true: because the risk of change is substantially higher in the backend, that is where the largest share of accumulated legacy is typically found.
How and when to update “legacy”?
There is no single correct answer; it all comes down to planning and foresight. It is not about drawing up a calendar to migrate old versions, but rather about creating deliberate decision points, factoring the cost into your projects, and above all, maintaining an agile and flexible architecture that can absorb constant upgrades without disruption.
The guiding principle remains consistent: minimise external dependencies and maximise code reuse across screens and applications.
The most common upgrade decision points:
- Regular security audits, weighted against the risk of known vulnerabilities
- New feature implementation, assessed against the scope of impact and dependency chains
The most common upgrade decision points
- Regular security audits, weighted against the risk of known vulnerabilities;
- New feature implementation, assessed against the scope of impact and dependency chains.
