AI With Legacy ERP: Integrate, Don’t Replace

Yes — AI works with legacy ERP software. You do not need to replace your fifteen-year-old ERP, WMS or planning package to use AI. A thin integration layer reads data through the APIs, database connectors or even exports your system already has, lets AI do the reasoning outside the old system, and writes results back as ordinary transactions. Replacement is a five-year project; integration is a sixty-to-ninety-day one.

Why "our software is too old for AI" is usually wrong

The fear is understandable: the vendor is gone or slow, the codebase is fragile, and the one consultant who understands the customisations is near retirement. But AI integration does not modify the legacy system at all — that is the whole trick. Even older SAP, Oracle, Exact or Unit4 installations expose data through APIs or ODBC/JDBC database connectors, and the crudest fallback — a nightly CSV export — is still a usable data feed. The AI layer sits next to the ERP, not inside it.

What actually disqualifies a system is rarer: no way to get data out at all (no API, no database access, no exports), or data so unreliable that no automation should trust it. The first is uncommon; the second is a data-quality project, not a reason to buy a new ERP.

The three integration patterns, from safe to deep

1. Read-only (mirror): the middleware only reads — orders, stock movements, invoices, hours — and the AI produces advice: exception lists, forecasts, anomaly alerts. Nothing writes back, so nothing can break. This is where every legacy integration should start, and a shadow-mode period of a few weeks proves accuracy before anyone acts on it.
2. Write-back through the front door: the AI creates draft transactions — a purchase proposal, an invoice coding, a planning suggestion — via the same interfaces a human user would use, and a person approves them inside the familiar ERP screens. The ERP stays the system of record; the AI is a very fast junior colleague.
3. Wrap-and-extend: for workflows the old system simply cannot do (document understanding, e-mail triage, customer-facing chat), the middleware exposes a unified API over the legacy core and new applications are built against that — leaving the ERP untouched underneath.

What this costs and returns — the honest version

Integration projects of this shape are weeks-to-months, not years. Industry guides quote 60–90 days to first production use via middleware, which matches what we see in Dutch SME practice: the first read-only use case (usually invoice exceptions, stock anomalies or planning alerts) live within two months. The payback logic is simple: pick one workflow where people currently retype, reconcile or chase data between the ERP and reality, and price the hours. If a planner spends 6 hours a week building the same Excel from ERP exports, that single workflow is ~280 hours a year — before you count the errors.

Costs scale with ambition, not with the age of your ERP: a read-only exception feed is a small project; write-back automation adds approval design and testing; wrap-and-extend is real software development. The expensive mistake is skipping straight to pattern three because a vendor demo looked good.

The five questions that decide your integration route

• Can data get out? API, database connector, or scheduled export — in that order of preference. Your IT partner can answer this in a day.
• Is the data trustworthy? If stock counts are fiction, fix counting before forecasting.
• Where is the pain repetitive? AI on legacy systems earns money in high-volume, low-variance work: coding, matching, checking, drafting.
• Who approves? Every write-back needs a named human owner inside the existing ERP screens — new interfaces kill adoption.
• What is the exit? Keep the middleware vendor-neutral so that when you DO replace the ERP in 2030, the AI layer and its history move with you instead of dying with the old system.

A worked example: invoice exceptions on an ageing ERP

The pattern we recommend most often as a first project, because every company has it: purchase invoices that do not match their order or receipt. In the classic setup, someone opens each mismatch, digs through the ERP, e-mails a colleague and parks the invoice for two weeks. With a read-only integration, the middleware pulls invoices, orders and receipts nightly; a language model classifies each mismatch (price difference, quantity difference, missing receipt, unknown supplier reference) and drafts the explanation and the e-mail to the right buyer. People stop investigating and start deciding.

The numbers behind it, with visible assumptions: a firm processing 12,000 purchase invoices a year with a 6% exception rate handles 720 exceptions. At 20 minutes each, that is 240 hours of skilled finance time. Classification plus drafting typically cuts handling to 5–7 minutes — roughly 160 hours saved, every year, from one read-only feed that touches nothing inside the ERP. That is the scale of win to expect from pattern one: not transformation, a solid recurring dividend — and a proof point that buys trust for pattern two.

Security, and the conversation with your IT partner

Legacy integrations fail on politics more than on technology, and the gatekeeper is usually your IT partner. Three agreements make that conversation work. First, access: a read-only database account or scoped API user, so the AI layer can never write outside its lane. Second, data boundaries: which tables leave the building, where they are processed (EU datacenters under a data-processing agreement), and what is logged. Third, responsibility: the IT partner keeps the ERP; the AI layer is a separate system with its own owner. Put those three on one page and most IT partners become allies — they have seen enough failed rip-and-replace projects to appreciate an approach that leaves their system alone.

Build or buy the middleware?

For standard connections, buy: integration platforms and the connector ecosystems around n8n, Make and the iPaaS vendors cover mainstream ERPs well. Build the thin custom part only where your competitive process lives — the extraction logic, the business rules, the AI prompts and evaluation. That split keeps you vendor-neutral (the exit question above) while avoiding months of plumbing work that off-the-shelf connectors already solved. What you should not buy is a black box that locks your ERP data into someone else’s cloud with no export path — that recreates the legacy problem one layer up.

What about AI agents that talk to the ERP directly?

The 2026 agent wave (MCP connectors, computer-use agents that click through screens) makes it tempting to skip the middleware and let an agent operate the ERP like a human. For exploration it works; for production it is fragile — screen-driven agents break on every UI quirk, and unmediated write access is exactly what the patterns above are designed to avoid. Agents belong on top of the integration layer, where their actions are typed, logged and approvable — not inside a twenty-year-old interface at 2 a.m.

Where to start

Map one workflow end-to-end, confirm the data path out of your ERP, and run pattern one in shadow mode for a month. That produces a business case with your own numbers instead of a vendor brochure. Our AI implementation approach and data engineering practice are built around exactly this route — and if you want a second opinion first, this is the conversation an AI consultant for SMEs should be able to have with your IT partner in one afternoon.

Frequently asked questions