AI Integration with Legacy Systems: Patterns That Work
AI integration with legacy systems rarely fails on the model. It fails on the first thing the model needs. That's a way to read the data and a way to write the answer back. The old system was built to be used by people through a screen, not called by software.
That's why the integration is usually the slow part of an AI project, and why it's worth choosing the pattern on purpose. Five patterns cover most cases. The right one depends on what the old system exposes today.
This article covers those five patterns and how to choose between them. It also covers what changes for ERP and CRM, and what AI agents add. It's for the CTO or architect whose AI use case depends on a system nobody wants to replace.
Key Takeaways
- How you connect AI to an old system depends on what that system exposes today: an API, a database, files, or only a screen.
- Putting a thin API layer in front of an old system usually pays back on the second AI use case, not the first.
- AI can read from an ERP freely but should write back only through the ERP's supported interfaces, never directly into its database tables.
- The common failure is an AI tool that never truly connects to the old system, so people copy and paste between the two.
- AI agents need APIs, real-time data access and separate identity checks, which many older systems weren't built to provide.
What Does AI Integration with Legacy Systems Involve?
AI integration with legacy systems means giving a model a safe way to read data from an old system and write results back to it, without replacing the system.
But age matters less than design. A legacy system, here, is any system that wasn't built to be called by software it doesn't know about. An on-premises ERP, a policy platform and a custom order tool all qualify.
The integration has three jobs. It lets the model read the data it needs. It lets the model's output land back in the system where the decision gets made. And it controls who and what is allowed to do both. Legacy system AI integration fails when one of the three is missing.
Enterprise AI integration at this level is foundation work. It's the stage of AI transformation that sets how far every later stage can go. It's also easy to underscope, because nothing about it is visible to a board.
Which Patterns Connect AI to Legacy Systems?
Five patterns connect AI to legacy systems: an API façade, change-data-capture, replication to a queryable store, a retrieval layer for documents, and screen automation as a last resort.
| Pattern | What it does | Best when | Watch for |
|---|---|---|---|
| API façade | A thin service in front of the old system exposes clean endpoints that the AI calls | The system has some usable interface, even an awkward one | The façade becoming a bottleneck or a single point of failure |
| Change-data-capture | Streams database changes into a queue, so the AI reacts to events | You need near-real-time reads and may read the database | Schema knowledge, and keeping it strictly read-only |
| Replication | Copies data into a store the AI can query | The use case is analytical or can tolerate stale data | Stale data, and access rules that must be copied too |
| Retrieval layer | Indexes documents and emails so models retrieve relevant passages | The knowledge lives in PDFs, emails and policies | Per-document permissions, and freshness |
| Screen automation | The AI drives the user interface | There's no API and no database access | Breakage when the screen changes, and weak audit trails |
Five is our grouping, not an industry standard. Real systems often combine two.
A common setup uses replication for reads and a façade for writes. The AI queries a copy, and it changes the old system only through controlled code.
The retrieval layer is the pattern most companies meet first, because so much knowledge sits in documents. Making it trustworthy is the work of AI knowledge management: clean documents, inherited permissions and sources shown with every answer.
The API façade is the default to reach for first. The AI calls the façade, never the old system, and the façade handles permissions, logging and rate limits. Microsoft's Strangler Fig pattern describes the same idea for migrations. An intermediary lets the old and new sides work together while the old system keeps running.
In our experience, an API façade in front of the old system pays back on the second use case, not the first. The first use case pays for the façade. But the second one reuses it.
Legacy system integration isn't new. What AI legacy system integration adds is a caller that's fast, tireless and unpredictable. And that's why the façade matters more than it used to.
How Do You Integrate AI with an ERP or CRM?
AI should read from an ERP or CRM freely but write back only through the interfaces the system supports.
ERP
An ERP holds the orders, inventory and financial records that most AI use cases need. Reading is usually safe: reports, the ERP's own APIs or replicated data give the model what it needs. But writing is where the care goes.
AI for ERP works best when the output is a suggestion or a pre-filled record that a person confirms. A model that reads an order document and pre-fills the order is useful on day one. A model that writes straight into the ERP's database tables isn't.
In our experience, direct database writes work in the demo and break at the next ERP upgrade. They also bypass the validations and audit trail that the ERP's own interfaces enforce. Use supported interfaces such as the ERP's own APIs, sanctioned import routines or integration middleware.
That's the core of AI ERP integration: read widely, write narrowly, and let the ERP keep enforcing its own rules.
CRM
A CRM holds activity notes, emails and customer history, which makes it a good source for summaries and next-step suggestions. The AI CRM integration question is mostly about permissions and data quality.
Record-level security has to carry through. A model that can see every account for every user will surface data the user was never meant to see. And write-back deserves caution. Let the AI propose a note or a next step. Keep a person confirming any field that feeds a forecast or a commission.
What Usually Goes Wrong When AI Is Bolted Onto Legacy Systems?
Most failures come from AI that never truly connects, or that connects in a way the next change breaks.
Deloitte's AI trends research asked AI leaders about agentic AI. Nearly 60 percent named two primary challenges: integrating with legacy systems, and risk and compliance. But the figure joins two challenges, so don't read it as 60 percent for integration alone. And it still says the same thing: integration and risk sit together.
Four patterns show up again and again.
The sidecar. A standalone AI tool runs beside the old system without connecting to it. People copy and paste between the two, and the time saved disappears into the copying.
Hidden business logic. The old system enforces rules nobody wrote down: a validation, a rounding rule, an approval threshold. An AI that bypasses the system's own interfaces bypasses those rules too.
One broad account. The integration runs on a single service account with wide rights. When something goes wrong, nobody can tell what the AI did or on whose behalf.
Silent failure. The integration breaks, the AI keeps answering from stale data, and nobody notices for a week.
Catch these early with a health check on the integration itself. Alert when the data is older than the use case can tolerate. Alert when error rates rise, or when a field the AI depends on changes. A model that answers confidently from stale data is worse than one that says it can't answer. Watch the model as well as the connection, because accuracy and cost fail as quietly as data does. That wider view is AI observability.
In our experience, the first integration is rarely blocked by the AI. It's blocked by one missing permission or one undocumented field. Find both before the build starts.
How Do You Choose an Integration Pattern?
Choose the pattern from what the old system exposes today, not from what you'd like it to expose.
| If the old system exposes | Start with | Why |
|---|---|---|
| A documented API or stable interface | A thin façade that calls it | The fastest path, and the façade adds logging and permissions |
| A database you may read, but no usable API | Change-data-capture or replication for reads, a façade for writes | Reads stay off the production path, and writes go through controlled code |
| Files and batch exports only | Replication to a queryable store | It matches the system's own rhythm and puts no load on production |
| Knowledge locked in documents and emails | A retrieval layer with per-document permissions | Models retrieve real passages instead of guessing |
| Only a screen, with no API or database access | Screen automation as a bridge | It's brittle and hard to audit, so plan its replacement |
An AI integration strategy is mostly this choice, made once per system. Pick the pattern and build the façade or the pipeline. And let later use cases reuse it.
Some teams argue that wrapping a legacy system only postpones its replacement. That's true over the system's life. But wrapping is the cheapest way to get a first use case live. It also shows what a replacement would have to support. It's the "retain" end of the 6 Rs of application modernization. If a system can't be wrapped at all, you're in replatform or replace territory, and that's a different project.
What Changes When AI Agents Connect to Legacy Systems?
AI agents raise the stakes on integration, because they act on systems instead of just reading from them.
Deloitte's Tech Trends 2026 names legacy integration first among the obstacles to agents: traditional enterprise systems lack the APIs, real-time execution, modularity and identity management that agents require.
Each of those maps to a control you build:
-
APIs: a façade, so the agent calls defined actions, not screens.
-
Real-time access: event streams or fast reads, so the agent doesn't act on stale data.
-
Identity: a separate identity for each agent, with the smallest rights that do the job.
-
Audit: a log of every action, with a way to switch the agent off.
Start read-only. And move to write access one action at a time, keeping a person approving anything that moves money or changes records. Deloitte describes the gap. But the controls are our recommendation.
Let's Sum Up!
The integration isn't the unglamorous part of AI. But it's the part that decides whether a use case ever reaches the business.
Choose the pattern from what the old system exposes. And build the façade once. Read widely, write narrowly, and give every agent its own identity and an audit trail.
If your use case is waiting on an old system, Classic Informatics builds this kind of AI integration for products and platforms, from the façade to the first live use case. We're here to help.
FAQS
Frequently Asked Questions
Yes. You connect through an API façade, change-data-capture, replication, a retrieval layer or, as a last resort, screen automation. Which one fits depends on what the old system exposes: an interface, a database, files or only a screen. Replacement only comes into play when none of those routes works or when the wrapper would cost more than a new system.
