Legacy System Integration: Connecting Old Software to New Tools

How do you integrate a system that has no API?

Legacy software usually offers one of a few doors. Pick the least invasive one that gives reliable results.

Whichever door you choose, record exactly what the integration reads and writes. Writes into a legacy database that bypass the application's own validation are the most common way integrations corrupt data, so prefer the application's import routines when they exist.

• Database access: read-only views or replicated tables expose data without touching application code
• File exchange: scheduled CSV, fixed-width or XML exports and imports over SFTP
• Message or socket interfaces: older TCP, MQ or serial protocols wrapped by an adapter
• Screen or terminal automation: a last resort for green-screen systems, fragile and slow
• Vendor modules: ODBC drivers, SOAP services or batch utilities the vendor already ships

What is the safest way to expose legacy data?

Place an adapter service between the old system and everything else. The adapter reads from the legacy interface, translates it into a clean REST API with JSON, and takes the load so the old system is not hit by every new tool. New applications never connect to the legacy database directly.

This also gives you a place to enforce authentication, cache frequent reads and log access, none of which the legacy system may support.

For systems with a database but no application API, change data capture or a nightly replica is often better than live queries. Staff keep working at full speed, and reporting or new apps read from the copy.

Why is legacy integration worth doing before replacement?

GAO found that agencies typically spend about 80% of IT funds on operations and maintenance of existing systems, and that the 10 systems it flagged ranged from about 8 to 51 years old. Replacing such systems takes years. An integration layer delivers value in weeks and also becomes the seam you cut along when replacement does happen.

The MuleSoft benchmark shows how rarely this is done: only 29% of applications in the average enterprise are integrated.

A common objection is that integrating a legacy system extends its life and delays the real fix. In practice the opposite happens: once data flows through a documented API, the old system becomes one replaceable component, and the business can retire it module by module when budget allows.

What are the risks of legacy integration?

Performance is the first: old databases may lack indexes, and an integration query can slow down daily operations. Vascoh schedules heavy reads off-peak and uses replicas where possible. Encoding is the second: EBCDIC, code pages and date formats such as YYMMDD cause quiet corruption.

Security is the third. Legacy systems may rely on shared logins, plain FTP or unpatched operating systems. The adapter should isolate them on a restricted network segment and permit only the specific connections needed.

Testing needs production-like data. Legacy systems often contain decades of odd records, such as blank dates, negative quantities and free-text in numeric fields, and an adapter must handle them without crashing.

Which legacy systems come up most often?

Typical targets are old ERP and accounting packages, AS/400 and IBM i applications, COBOL batch systems, custom Access or SQL Server 2008 databases, and industry-specific packages whose vendors have disappeared. Each one has its own quirks, which is why the first step is always reading the system rather than assuming how it behaves.

Documentation is often missing, so Vascoh builds a data dictionary while integrating: field names, formats, valid values and which screens write them. That document is useful long after the project, especially if replacement is planned, because it records what the old system actually stores.