How to Integrate Modern Applications with Legacy Software

Consider a textile unit running a mainframe-style billing and stock program installed almost two decades ago, with no vendor support left and no modern API. The first job is an audit of what it can really offer: a scheduled export, a working file format, a queryable database, or only a terminal screen.

That audit decides everything after it. A program that already drops a nightly export file is in a different position from one reachable only through a clerk’s keyboard, so one plan cannot fit both. Look in odd places too: an SFTP folder where a forgotten job drops fixed-width text files, or a spooled report that someone prints every night and nobody reads.

Rank the options in this order. A documented API comes first, even a limited or old one, because the vendor designed it to be called by other programs. Next comes a reliable scheduled export, such as a nightly CSV of the day’s transactions, which middleware between the old and new systems can pick up and validate.

Robotic process automation is the last resort. It drives the legacy screen as a person would, clicking through menus, so a moved field, a renamed button or a patch can break it silently. It is also harder to monitor, since a clicked button returns no status code and a failed run may surface only when someone spots a missing record.

An unused export changes everything. For the textile unit, finding a nightly stock export that nobody had opened would turn what looked like a screen-automation project into a simple file-processing job.

Old systems break easily. A badly built integration that queries the database directly can slow the clerks still using the system all day, or in the worst case corrupt live records. Use a dedicated read-only account for any direct database connection, and test every write on a copy of production long before it touches the real thing.

Take a backup before the first connection. Restore it on a spare machine, so experiments with queries and test imports happen away from the live billing system and nobody loses an afternoon’s invoices.

Ownership needs to be explicit too. If the old system owns stock levels or customer balances, the integration must respect that, or the new tool becomes the source while the old one drifts. Nobody notices until totals disagree.

Legacy interfaces behave inconsistently, so check every value leaving the old system, including date format, quantity range and item code, before anything downstream trusts it. Reject bad rows loudly. Old exports often arrive in a legacy charset, with long item names cut by truncation, so define one canonical record format on your side and convert everything into it.

Reconciliation is the second habit. Each week, compare a sample of invoices and stock movements in both systems to catch the slow drift that fragile connections produce. Catching a mismatch early costs an afternoon, while a mismatch found at year-end can mean rebuilding months of ledger entries by hand.

Keep a rollback path as well. If an import posts wrong quantities into the new system, you should be able to reverse that batch by its run number instead of editing rows by hand.

It is a bridge, not a destination. From the first day, the plan should name what replaces it, whether that is migrating the data into a modern system or obtaining a proper API from the vendor.

Until then, watch it closely. Give it a named owner, a daily success check and an alert for any morning the expected export file fails to arrive on schedule.

Agree the exit triggers early: the end of a support contract, a repeated failure of the automation, or the day the last clerk stops using the old screens. Whichever comes first starts the project.