Your 2009 ERP Can Still Talk to AI. Here's How.

The system nobody may touch

Every company past a certain age has one: the ERP installed when the office had a fax machine, written by a vendor that may no longer exist, holding the single most valuable dataset the company owns. Everyone agrees it's ancient. Everyone also knows the business stops if it stops.

So when someone says "let's automate," the room looks at the ERP and someone says the sentence that kills the meeting: "It doesn't have an API."

That sentence is doing less work than it thinks.

AI needs an interface. It doesn't care which one.

Modern agents work through structured tools, MCP being the emerging standard, but a "tool" is just a wrapped capability. The wrapping can go around almost anything:

1. The humble export. Your 2009 ERP can't do webhooks, but it can dump a nightly CSV, it's been doing it for years. Workflows watch the export, agents read it, and the reporting and reconciliation layers work from data that's hours old. For most back-office automation, hours-old is fine, and it's exactly how you automate production reporting in a plant whose ERP predates the concept of an API, or reconcile OEE without an MES.

2. The database underneath. The application is elderly; the database under it is usually a plain SQL database, readable today. Read access alone unlocks enormous ground, order status, stock levels, customer history, without touching the app. Writing directly is a different animal: it bypasses the app's business logic, so it needs vendor guidance, staging tests and checkpoints. The common pattern: read from the database, write through a supported channel.

3. RPA as the hands. Where the only way in truly is the green-screen form, keep the agent-does-the-thinking, RPA-does-the-typing hybrid: the agent reads the messy order, decides what should be entered, and a scripted step performs the entry it would be brittle to ask a human-mimicking bot to decide.

4. The custom connector. Whatever interface exists, a SOAP endpoint from 2011, a COM object, a folder of fixed-width files, gets wrapped once as a custom MCP tool, and from then on every agent on the platform can use it like any modern integration. Build the bridge once; reuse it for every automation after.

The order of operations

Teams get this backwards and pay for it. The failure mode: "first we'll migrate to a modern ERP, then automate." The migration takes two years, the automation never starts, and the pain that motivated everything continues throughout.

The working order: automate against what you have, starting with read-only wins, reports, lookups, order intake queued for approved posting. The judgment layer you build is portable; if you migrate someday, you swap the bridge, not the brain. Reading the item master is also where PPWR compliance data collection starts, weight and material codes are usually already sitting in the ERP you have, not a system you'd need to buy.

Legacy systems are the hard end of a general problem. If you're mapping the whole estate rather than one stubborn ERP, the four connection surfaces and how to choose between them covers the modern systems too.

One honest caveat: the bridge is where project cost lives. A documented API is cheap; archaeology isn't free. Get the integration surface assessed before trusting any quote, it's the first thing we look at.

The takeaway

"No API" ends conversations that should be starting them. The data is right there, behind an export, a database, a screen or a wrapper, and the companies getting automated aren't the ones with modern ERPs. They're the ones who stopped waiting for one. Common ground for this work: manufacturing, wholesale, logistics.