Integrating an agent with a legacy ERP when there is no API
"It can't be done here, our system is from 2011" is a sentence we hear regularly and one that is almost never true. A legacy ERP with no modern programming interface does change the project — it raises the cost of integration, sometimes by a factor of two, and forces a more careful approach to writing data. But it rarely settles the question of feasibility. Below are four ways in that we use to connect an agent to systems without an API, along with what each one costs and where it runs out.
- No API is a question of integration cost, not feasibility — there are usually several ways in.
- Reading from the database is the most common solution; writing calls for far more caution.
- The worst case is not an old ERP — it is a system with no documentation and nobody who knows it.
Four ways in
The order below matches what we check during the audit — from the cheapest and safest to the last resort.
The database, read-only. The most common solution and usually enough. The agent reads stock levels, statuses and counterparty data straight from the database, on a separate account with permissions limited to selected views. It writes nothing, so the risk on the ERP side is close to zero.
Exports and exchange files. Almost every system has some export to CSV or XML, often already used for reporting. Slower than reading from the database and delayed by whatever the schedule is, but it needs no access to the inside of the system at all.
An intermediary layer over the database. If writing is needed too, we build a thin layer that exposes controlled operations and enforces the ERP's business rules. This is the item responsible for most of the cost difference against a system with a ready API.
User interface automation. The agent drives the screen the way a person would. It works everywhere, but it is brittle: any change to the screen layout can break it. We treat it as a last resort for individual operations that cannot be done any other way.
Reading and writing are two different conversations
It is worth separating them at the very start, because their risk profiles have nothing in common. Reading is reversible: if the agent misreads the data it will say something untrue, but it will break nothing. Writing is irreversible and subject to rules that in legacy systems are often buried in the interface rather than the database — inserting a record while bypassing those rules can put the ERP into a state the system does not anticipate.
So in most implementations we start with an agent that only reads, preparing every change for a human to approve. That usually covers most of the value in the process at a small fraction of the risk. Writing goes in as a second step, for a narrow range of operations, after testing on an environment restored from a backup.
The real consequence of a legacy system. A far more serious problem is having nobody who knows how that system is configured — no budget makes up for that.
What actually gets in the way
Not the age of the system, but the knowledge about it. If the ERP has been customised repeatedly by a company that no longer exists, there is no documentation, and the person who knew it has left — the time needed just to work out where the right data sits can exceed the time needed to build the agent. That is the situation in which we genuinely advise against starting and propose an inventory first.
The second obstacle is a service agreement that forbids database access on pain of losing support. It comes up less often than meeting-room talk suggests, but it does come up — which is why before the audit we ask you to check the terms of your contract with the ERP vendor. If such a clause exists, what remains is exports and an intermediary layer on the vendor's side, which changes the schedule but does not close the subject.
Frequently asked questions
Do we need to replace the ERP before implementing AI?
No, and we advise against combining the two projects. Replacing an ERP is a separate, far larger undertaking; the agent connects to the system you have. If a replacement is planned anyway, it is worth designing the integration so it can be re-pointed later — but not waiting for it before you automate.
Isn't database access a risk to the data?
Access is granted on a separate account, read-only and only to the specified views — narrower, in other words, than what most people in the department have today. Every query is logged. That is usually safer than exports circulating as files in mailboxes.
How long does integration with a system without an API take?
Reading from the database usually fits inside the pilot schedule. An intermediary layer with write access adds weeks, and it is mainly that which drives the difference in the quote. We settle the exact scope during the audit, when we can see the data structure rather than a description of the system.