Connecting AI to legacy systems with no API

The situation we meet most often

An ERP more than a decade old, running on its own server, its vendor long inactive, and IT holding one rule: do not touch it.

This is not an edge case. It is the normal condition of Indonesian companies that have been operating for a while, and it is precisely those companies that carry the most manual work — because the system works well enough to keep, but is not open enough to connect.

The "do not touch it" rule is usually rational in itself. That system holds years of transaction data, nobody really understands its internals any more, and there is no test environment that matches production.

Three integration routes

There are three ways to connect something to a system that was never designed to be connected. All three are legitimate, and the choice is dictated by what the system permits, not by technical preference.

API integration

The cleanest route where the system supports it. Data flows both ways, every call can be audited, and the contract is explicit so a change on either side surfaces quickly.

Some older systems in fact have an API that was never used — bought as an add-on module, then forgotten. This is among the first things we check.

Database connector

For systems without an API. Access is read-only against a replica, not the primary, so query load and the risk of error never touch the system currently serving operations.

The trade-off: a database schema is not a public contract. It can change when the system is patched, without notice. So integration by this route is always paired with shape validation on our side, and an alarm when the shape changes.

RPA

The last resort for systems reachable only through their interface. It works, and for some cases it is the only thing that works.

But it is fragile against UI changes — a single cosmetic update can halt an entire flow. So we never deploy RPA alone: always with monitoring that detects failure faster than a user report, and a clear escalation path to a human.

File exchange, the one people forget

Beyond those three, many older systems already have a scheduled export that has been running for years. A CSV landing in a network folder every night is still a legitimate integration contract — the format is stable, it puts no load on the source system, and it needs no new access permissions.

This route is often dismissed as old-fashioned. Yet for processes that do not demand instant results, it is the cheapest and the most durable.

Technology is not what decides it

If the process itself is unclear,
even the best integration only speeds up the mess.

The order is always the same: clarify the process, decide where it should connect, then choose how to connect it. Reversing that order produces an integration that is technically tidy but wired to the wrong thing.

On security and compliance

The first question from IT is almost always the same: where does this data go.

The answer depends on the architecture chosen, and that is a decision taken at the start rather than at the end. Deployment can be on-premise, in a private cloud, or inside your own VPC — following the data policy already in force, rather than forcing the policy to accommodate the tool.

For some clients this means not a single piece of operational data leaves their network. That is a constraint that can be met, and it is better stated at the outset than discovered mid-implementation.