There are five API integration options that work on Australian legacy systems: a CSV-to-API bridge, database change data capture, a webhook shim, a durable queue between old and new, and off-the-shelf iPaaS tools like Zapier or Make. Most SME projects start with the CSV bridge - it needs no change to the legacy system at all.
- Most common starting pointCSV-to-API bridge (no legacy change required)
- Fastest to near real-timeDatabase change data capture
- Try before buildingZapier, Make or Workato
- Makes it production-safeA durable queue (AWS SQS, Azure Service Bus)
- Typical timeline2-4 weeks for a CSV bridge, 4-8 for CDC
The reality of most Australian SMEs
A legacy ERP that can only export CSV at midnight. A CRM someone half-adopted. Finance on one system, ops on another, marketing on a third. Someone in the middle is holding the whole thing together with email rules and a diary reminder. Sound familiar?
You don't have to replace anything to start
Modern API integration services don't require green-field systems. A good integration layer reads what the legacy system produces - even if that's a CSV on an FTP server - and exposes it as clean API events to the rest of the business.
The top API integration options for legacy systems
Five patterns cover almost everything we see in Australian SMEs. They are not mutually exclusive - a real project usually combines two or three - but this is roughly the order we assess them in, from least invasive to most.
1. CSV-to-API bridge
A scheduled worker picks up the exports the legacy system already produces, validates them, and pushes the data into downstream systems via their APIs. Nothing about the legacy system changes - you are consuming an output it has been generating all along, usually at midnight, usually to a folder nobody looks at.
Best when: the legacy system has no API but does have a reliable export. Watch for: export latency, which caps how fresh downstream data can be, and schema drift when someone adds a column.
2. Database change data capture
Where we can read the legacy database directly, we detect changes - by timestamp column, by trigger, or with log-based CDC - and stream them out as events. This bypasses the legacy application layer entirely, which is often the slowest and most fragile part of the system.
Best when: you need near real-time and the database is accessible. Watch for: undocumented schemas, which is where the time actually goes, and vendor support agreements that prohibit direct database access.
3. Webhook shim
Plenty of older systems can fire a basic HTTP call but nothing beyond that - no auth, no retries, an arbitrary payload shape. A shim receives that call, normalises the payload into a clean internal schema, and fans it out to whichever systems need it.
Best when: the legacy system has some notification capability, however primitive. Watch for: no delivery guarantee - if the shim is down, the event is gone, so pair it with the queue below.
4. Durable queue in the middle
A managed queue such as AWS SQS or Azure Service Bus sits between the old and new systems. This is less an integration pattern in its own right than the thing that makes the other four production-safe: a slow or offline legacy system stops being able to take down the modern ones.
Best when: always, honestly, once you are past a proof of concept. Watch for: nothing much - this is the cheapest resilience you will ever buy.
5. Off-the-shelf iPaaS (Zapier, Make, Workato)
Rule this in before building anything. Integration platforms handle the simple cases well, cost nothing to trial, and need no developer. If Zapier connects both ends and the logic is field mapping, you are finished for a monthly fee.
Best when: both systems have modern connectors and volumes are modest. Watch for: per-task pricing at volume, no connector for the legacy system (the usual blocker), transformation logic beyond mapping, and thin error handling when a run fails at 2am.
If you want this applied to your own stack rather than described in the abstract, that is what our API integration services cover.
What "done" looks like
- Orders flow from the legacy system into the CRM automatically, with retry and alerting.
- Finance gets a daily reconciliation report instead of three people copy-pasting.
- The legacy system can be replaced on a slow timeline - because nothing else depends on its exact shape anymore.
For a worked example of the same philosophy applied end-to-end, see the BI Sense case study and the Furniture Court case study.
What to avoid
- Direct-to-direct integrations. System A hitting System B's API directly. Fine until A goes down. Use a queue.
- No idempotency. Re-running a failed job shouldn't create duplicate orders.
- No observability. If you can't see failures, they don't exist until the finance team complains.
Legacy system integration: frequently asked questions
Five patterns cover almost every case: a CSV-to-API bridge that consumes the exports the legacy system already produces; database change data capture where the database can be read directly; a webhook shim that normalises basic HTTP callbacks; a durable queue such as AWS SQS or Azure Service Bus between old and new; and an off-the-shelf iPaaS like Zapier, Make or Workato for the simple cases. Most Australian SME projects start with the CSV bridge because it needs no change to the legacy system.
Almost always, yes. A system with no API still produces something - a scheduled CSV export, a report drop on an FTP server, a database you can read, or a printable file. Any of those can be turned into a clean API surface by a bridge sitting alongside it. Replacing the legacy system is rarely the prerequisite people assume it is.
Try Zapier or Make first - if they handle it, you are done for a monthly fee and no build cost. They stop being the right answer when the legacy system has no connector, when volumes make per-task pricing painful, when you need transformation logic beyond field mapping, or when you need real error handling and replay. That is the point at which custom pays for itself.
A single CSV-to-API bridge with validation, retry and alerting is typically two to four weeks. Change data capture on a legacy database runs longer, four to eight weeks, because the discovery work on an undocumented schema is the bulk of it. Multi-system programmes are scoped in phases so something is in production early rather than everything landing at once.
Direct point-to-point connections. System A calling System B's API directly works fine until B is down or slow, and then A fails too - and you have built exactly the tight coupling you were trying to escape. Put a durable queue in the middle. The other two are missing idempotency, so a re-run creates duplicate orders, and no observability, so failures are invisible until finance complains.
Not on anyone else's timeline. The point of an integration layer is that nothing downstream depends on the legacy system's exact shape any more, so you can replace it when the business case is ready rather than when it finally breaks. Several clients have run the bridge for years and never replaced the original.
Got a legacy system you can't get off - but need to integrate around?
Tell us what it is and what needs to flow in or out. We'll scope a clean path.