How to Integrate AI With Legacy Systems Without a Migration

Every organisation running AI initiatives hits the same wall. The data that would make the AI useful lives in a system nobody wants to touch: a mainframe, a decade-old ERP customisation, a vendor product whose integration story is a nightly CSV.

The instinct is to fix the system first. That instinct is usually wrong, or at least wrongly sequenced.

Why the valuable data is always in the worst system

This is not bad luck. It is selection effect.

Systems become legacy by being load-bearing for a long time. The claims database is old because it has been processing claims for fifteen years. Longevity is why it is fragile and why its data is worth something - the same property produces both.

So "we will modernise it, then add AI" means postponing the AI work behind the single hardest programme in your portfolio.

The migration trap

The standard proposal: move the data somewhere modern, then point AI at the copy.

Sometimes right. Often a trap, for reasons that show up months in:

The copy goes stale. Now you have two sources of truth and a sync job. The AI answers from the copy; the business operates on the original; they diverge quietly and you find out from a customer.

The hard part was never storage. Legacy data is difficult because of undocumented business rules, encoded meaning in unlikely columns, and thirty exception cases the system encodes as conventions. Copying rows does not copy that. It strands it.

The timeline outlives the mandate. Migrations run long. AI initiatives are funded on shorter cycles. The migration becomes the project and the AI work never starts.

Migration can be the right answer - when the system is genuinely being retired for reasons that already stand on their own. It is a bad prerequisite for an AI project.

The read-only wedge

The alternative is narrower and much faster: leave the system alone and give AI a read path to it.

Not a copy. A live, permissioned, task-shaped interface over the system as it exists. Concretely, that is what a Model Context Protocol server does - it wraps a system and exposes what it can do in a standard shape, without changing the system.

The wedge is read-only at first, deliberately. Reading is where most value sits early, the blast radius is small, and it buys the thing you actually lack: evidence about whether the AI is useful against this data before you have spent a year moving it.

Step 1: pick the question, not the system

Do not start with "expose the ERP". Start with a question a person answers by hand today.

"Which shipments are at risk this week?" "Does this customer's contract cover this?" "Why did this transaction fail?"

A specific question tells you which fields, which joins, and which business rules matter. It scopes the work to days. "Expose the ERP" scopes it to a quarter and delivers a surface nobody uses.

Pick a question that is asked often, answered slowly, and where the answer is checkable. Checkable matters - you need to know whether the system is right.

Step 2: find a boundary that already exists

You need a way in that does not mean modifying the legacy system. Options, roughly best to worst:

An existing API. Even a partial or ugly one. Already has auth, already has an owner.
A read replica or reporting database. Common, usually already provisioned, and read-only by construction.
A stored procedure or view layer. Older systems often have one for reporting. Extend it rather than reaching past it.
A file drop or scheduled export. Batch, so accept the staleness explicitly and tell users the data's age.
Direct database reads against production. Last resort. If unavoidable, use a dedicated read-only account with a strict connection cap.

The near-universal mistake is reaching around the system's own boundaries — querying tables directly when a service exists. It works in a demo and breaks on the next vendor upgrade, because you coupled to an internal schema nobody promised to keep stable.

Step 3: model tasks, not tables

Do not expose the schema. Expose the question.

A table-shaped interface hands the model forty columns with names like STAT_CD_2 and expects it to infer that 7 means "held for manual review". It will guess, confidently, and be wrong.

A task-shaped interface offers get_shipments_at_risk(week) and returns a small, clean, named result. All the domain knowledge — which status codes count as at-risk, which exceptions to exclude - lives in your server, written once, by someone who knows, and testable.

This is the step that most determines whether the project works. It is also the step that needs the person who understands the old system, which is usually the real scheduling constraint.

Step 4: solve identity before you widen access

The question to answer early: when the AI reads a record, whose permissions apply?

If your server holds one service account, every user effectively has that account's access. Any row-level security in the legacy system is now bypassed - and legacy systems often carry decades of carefully accreted access rules.

Propagate the end user's identity through to the underlying query so existing controls still apply. Retrofitting this later means redesigning the server, so it is worth the friction on day one even for a pilot.

Step 5: instrument before you expand

Log every call: who asked, what was invoked, what arguments, what came back, how long it took.

Two reasons. The obvious one is audit. The less obvious one is that these logs are your specification for what to build next - the questions people actually ask are rarely the ones you predicted, and the failures cluster in ways you would not have guessed.

Get this in place before widening access, not after.

Handling the genuinely hard cases

No API, no replica, no appetite for direct reads. Sometimes the only sanctioned path is a batch export. Accept it, be explicit about staleness in the interface ("as of last night's export"), and use it for questions where day-old data is genuinely fine. Do not paper over it - a model that presents stale data as current will burn user trust permanently.

Meaning encoded in conventions. Status codes, magic numbers, a notes field carrying structured data by informal agreement. This is knowledge extraction, not engineering. Budget time with the people who know, and write the rules down in the server where they can be tested. This is often the single most valuable artifact the project produces.

A system that cannot take the load. Older systems sometimes cannot absorb an unpredictable query pattern. Cache aggressively, cap concurrency, and put a circuit breaker in front. A model in a retry loop can generate more traffic than you expect.

Contradictory sources. Two systems disagree about the same customer. Do not let the AI pick silently. Either resolve the precedence rule explicitly in the server, or return both and say they disagree. Silent resolution is how you get confident wrong answers.

What this does not fix

Being straight about the limits:

It does not improve your data. Wrong data becomes wrong answers, delivered faster and with more confidence. If the underlying records are bad, fix that first - the interface will only make it more visible.
It does not remove the case for modernisation. If the system is genuinely at end of life, it still is. This decouples the AI work from that programme; it does not cancel it.
It does not make writes safe by default. Read-only is a deliberate starting position. Adding write access is a separate decision with a much larger blast radius, and it needs idempotency, approval steps, and a rollback story before you turn it on.
It is not free. A wrapper is production infrastructure with an owner, a test suite, and a lifecycle. Unowned, it rots - and a rotting service that AI calls autonomously is worse than no service.

The claim is narrower than "AI without migration" makes it sound: you can get real value from legacy data on a timescale of weeks rather than quarters, and you learn whether the AI use case is worth anything before committing to the expensive programme. That is usually the right order.