Connecting AI to Legacy Systems: Integration Patterns That Avoid a Rewrite

The systems that hold most companies’ critical data — ERPs, core banking, policy administration, warehouse management, bespoke line-of-business applications — were built long before language models. They often lack modern APIs, use cryptic data models and are maintained by small teams who are wary of change. Yet AI features need exactly the data and actions these systems hold.

The good news is that a rewrite is rarely necessary. This guide covers integration patterns that let AI work with legacy systems safely. For broader guidance on adding AI to an existing product, see our guide to adding AI to an existing application.

What AI features need from legacy systems

• Read access to current data: customer records, orders, policies, stock, transactions.
• Historical data: for analytics, model training and retrieval.
• Controlled actions: creating a ticket, updating a status, placing a hold — usually few and well-defined.
• Change notifications: knowing when something changes, so AI outputs stay current.

Each has a different integration answer.

Integration patterns

The anti-corruption layer matters more with AI

Legacy data models often use abbreviations, overloaded fields and status codes that only long-serving staff understand. If those leak into prompts and tool definitions, language models misinterpret them. An anti-corruption layer — a term from domain-driven design — translates them into clear names and values: STAT_CD = 7 becomes status: “awaiting_customer_documents”. This makes AI tools easier to describe, reduces errors and isolates the AI layer from future changes to the legacy system.

Choosing an API style

Protecting the legacy system

Legacy systems are often sized for their original workload. AI features can multiply query volumes, especially agents that call tools repeatedly.

• Rate-limit and queue calls from AI components.
• Cache reference data and slow-changing records in the facade.
• Serve reads from replicas or the data platform where freshness requirements allow.
• Use CDC rather than polling to detect changes.
• Keep writes narrow: a small set of well-defined commands that go through the legacy system’s own business logic, never direct database updates.
• Monitor latency and error rates of legacy calls separately and set circuit breakers.

Security and compliance

• Give AI components their own service identities with least-privilege access to the facade, not credentials for the legacy system itself.
• Filter data by the end user’s permissions before it reaches a model.
• Mask or omit personal data the AI feature does not need.
• Log every call with user, purpose and data returned, for audit and data-protection obligations.
• Check data residency: legacy data sent to an external model provider may be subject to contractual or regulatory limits.

Worked example: claims assistant for an insurer

A hypothetical insurer wants an assistant that helps claims handlers summarise a claim and draft next steps. Claims live in a 20-year-old policy administration system with a database and a SOAP interface.

1. Facade: a REST API offers four read operations — claim summary, policy cover, payment history, correspondence list — and one write: add a note to the claim.
2. Anti-corruption layer: translates claim status codes, cover codes and party roles into readable values.
3. CDC: streams claim and correspondence changes into a search index used for retrieval.
4. AI layer: the assistant calls the facade as tools, retrieves documents from the index and drafts a summary for the handler.
5. Controls: read access is scoped to claims assigned to the handler’s team; the only write is adding a note, which the handler confirms.

The legacy system is untouched apart from read-only database access for CDC and the existing SOAP calls behind the facade.

Testing the integration

• Contract tests on the facade so changes to the legacy system that break the translation are caught immediately.
• Realistic test data copied and masked from production, because legacy data contains edge cases no synthetic set anticipates.
• Load tests that simulate AI traffic patterns — bursts of tool calls — against a production-like legacy environment.
• Failure tests for timeouts and unavailability, confirming the AI feature degrades gracefully rather than retrying aggressively.

A phased plan

1. Map the use case to the data and actions it needs.
2. Assess each system: available interfaces, database access, load capacity, data quality, owners.
3. Build the facade and anti-corruption layer for the minimum set of operations.
4. Add data feeds with CDC or batch for retrieval and analytics.
5. Pilot read-only AI features, then add narrow write actions with confirmation.
6. Use the facade for future modernisation: once consumers depend on the facade rather than the legacy system, the system behind it can be replaced piece by piece — the strangler fig approach Martin Fowler described in 2004.

Frequently asked questions

Can AI agents use the legacy system’s user interface directly?

Computer-use and RPA tools can, but they are slow, fragile and hard to secure. Use them only as a temporary bridge where no API or database access exists.

Do we need to clean legacy data before using AI?

For the fields the use case depends on, yes. Translate and validate them in the anti-corruption layer, and fix the most damaging quality problems at source.

Will integrating AI slow down the legacy system?

It can if AI components query it directly and repeatedly. Caching, replicas, CDC and rate limits protect it.

Is this a step towards replacing the legacy system?

It can be. A facade that consumers depend on lets you replace the system behind it gradually, without changing every consumer.