AI and Legacy Software: 4 Approaches Without Rewriting

Key Takeaways

1AI can be added to legacy applications without a complete rewrite, preserving the core system.

2Four isolation architectures are detailed: middleware, RAG, event-driven integration, strangler fig pattern.

3Progressive governance: starting in read-only mode, human validations, ongoing operational budget (token billing, monitoring, retraining).

Why it matters : These methods allow for the modernization of existing systems while minimizing risks, costs, and disruptions.

Replacing a system that has been in place for years is neither a necessary step nor, often, a good idea. Several methods allow for the addition of AI around an intact application core, provided that access is framed, ongoing costs are anticipated, and an appropriate architecture is chosen. Here’s an overview of the options, preliminary checks, and recurring pitfalls.

Anticipate Costs and Limit Access from the Start

Commercial language model APIs are generally charged by token. In addition to these costs, expenses related to monitoring, evaluation, and retraining arise, requiring ongoing financial commitment after deployment. Teams that approach an AI layer as a one-time operation frequently experience performance loss over time as data and context evolve, while an operational budget planned from the outset helps maintain reliability stability. On the governance side, the recommendation is to start with read-only use cases—search, synthesis, reporting—to establish accuracy measures before any actions that modify data. Write access comes later, accompanied by human approval steps for sensitive operations.

Four Architectures to Isolate the Application Core

Keeping AI at a distance from the central system is presented as the safest option. One approach is to insert a middleware layer that only exposes defined operations, preventing arbitrary requests on the production database and limiting the risks of overload, query errors, or prompt injection. Augmented generation through retrieval offers a second avenue: data remains in the legacy system, while a separate pipeline indexes useful content in a vector database and allows for enriched responses with citations for verification. The third approach, event-driven integration, relies on the emission of events or the capture of change data—insertions, updates, deletions—to trigger AI services in near real-time, capable of, for example, flagging suspicious transactions or predicting delays without burdening the legacy application. Finally, the strangler fig pattern—named by Martin Fowler—replaces or augments functions piece by piece via a façade, allowing the old system to continue operating while the balance evolves without a risky single cutover.

Le brief IA que lisent les pros

Le brief IA que les pros lisent chaque soir

Les 7 actus IA du jour, décryptées en 5 min. Gratuit.

Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.

Choisissez votre rythme

Gratuit · Pas de spam · Désabonnement en 1 clic

Why Avoid General Rewriting

Legacy applications incorporate years of business rules, special cases, and regulatory logic, rarely documented exhaustively. A rewrite requires rediscovering these elements while keeping the existing system in production, with replacement projects known for exceeding budgets and timelines, some of which do not succeed. Moreover, AI performs better on reliable data and stable processes: the test of time provides a solid foundation that a mature system precisely offers.

What the State of the System Requires Upfront

Before any development phase, it is essential to determine whether the system can provide data via APIs or if creating an additional integration layer is necessary. The quality and uniformity of the data determine a model's ability to extract or assimilate information. It is also important to identify the owners of the relevant processes and the applicable security and compliance requirements, as these elements will guide the architecture and reduce the risk of surprises during the project.

Add a Layer, Don’t Rebuild: The Recommended Path

Many organizations assume that AI requires everything to be rebuilt, which hinders initiatives, while rewriting a system that has been in place for 15 years is costly, risky, and rarely necessary. In most cases, AI can be added as a layer rather than as a new foundation. Development companies position AI as an extension of the existing system; for example, SumatoSoft describes adding an intelligent layer without destroying what works. Legacy software often concentrates the most valuable knowledge of the business; an AI layer can transform these assets into an advantage rather than a migration project. The proposed trajectory is to start with a narrow use case and let real results guide the scale of the rollout.