How to Integrate Modern Applications with Legacy Software

Imagine a textile manufacturing unit running an on-premise billing and inventory system installed close to two decades ago, with no vendor support left and no modern API. Before anything else, someone needs to establish, concretely, what that system can actually offer: does it export any files on a schedule, does it have an old but functioning API or file format, can its underlying database be queried directly, or is a screen — a terminal or old desktop application — genuinely the only way in?

This inventory determines everything that follows. A system with even a basic scheduled export is in a completely different situation from one where the only access point is a person's screen, and conflating the two leads to either overbuilding for a simple case or underestimating a genuinely hard one.

In order of preference: a documented API, even a limited or old one, is almost always the safest option, since it was designed by the vendor to be used this way. Next best is a reliable scheduled file export — a nightly CSV of the day's transactions, for instance — which can be picked up and processed by middleware built to sit between the old and new systems.

RPA — robotic process automation that operates the legacy system's own screen the way a person would, clicking and typing through its interface — is the last resort, not the first choice, because it's fragile: it breaks the moment a screen layout, a field position, or a system update changes anything the automation was built around, and it typically can't be secured or monitored the way a real API integration can.

For the textile manufacturer, this might mean discovering the old system does have a nightly export file nobody had been using, which turns what looked like an RPA project into a much simpler file-processing one.

Legacy systems are frequently more fragile than they look, and a poorly built integration touching them directly — especially via database access — carries real risk of corrupting live production data or degrading performance for the people still using the system daily. Any direct database connection should, wherever possible, use a dedicated read-only account, and write operations against a legacy system deserve far more caution and testing than the equivalent operation on a modern, well-documented API.

Ownership also needs to be explicit: if the legacy system remains the system of record for certain data, the new integration should reflect that rather than quietly becoming the 'real' source while the old system drifts out of date and nobody notices until a discrepancy surfaces.

Because legacy interfaces are often less well documented and less consistently behaved than a modern API, validation matters more here, not less — checking that a value coming out of the old system is actually in the expected format and range before it's trusted by anything downstream.

A reconciliation habit — periodically comparing a sample of records in the old and new systems to confirm they still agree — catches the slow drift that's common with fragile legacy connections, especially RPA-based ones, before it becomes a larger discrepancy that's expensive to untangle.

A legacy integration, particularly one built on RPA or direct database access, should be treated as a bridge, not a destination. The plan from day one should include what replaces it — whether that's eventually migrating the underlying data to a modern system entirely, or the vendor releasing (or being pushed to release) a proper API.

In the meantime, the fragile connection deserves closer monitoring than a normal API integration would, precisely because it's more likely to break silently when the legacy system changes in ways nobody outside its original vendor fully documented.