It is rare for a business to build on empty ground. Usually there is accounting software that has run for years, a sales system in daily use, and now something new is needed — with no day of trading allowed to stop.
There are four ways to connect them, and choosing wrongly causes most of the trouble that follows.
Way 1: Call each other’s APIs
The best option where it exists. Two systems exchange through a published interface, each protects its own data, and each can change internally without breaking the other.
- Upside: near-immediate updates, permission control, a log of every call.
- Downside: you depend on the quality of the other side’s API. Undocumented APIs, no test environment, or changes shipped without notice are all very real problems.
- Ask before choosing: is there documentation, is there a sandbox, what is the rate limit, and who notifies you when the API changes?
Way 2: Scheduled batch sync
Copy data from one system to the other each night, or each hour. Simple, easy to monitor, easy to re-run after a failure.
Suited to data that need not be instant: product catalogues, price lists, data for reporting. Not suited to stock in a fast-selling environment — a night of lag is enough to oversell.
Way 3: Read the legacy database directly
Fast and cheap when the old system has no API. But it is a debt-taking option: you become dependent on the internal structure of software you do not control. They ship an upgrade, rename a column, and everything breaks at the worst moment.
If you must: read only, never write, and alert on schema changes. Writing directly into another system’s database is the surest way to corrupt data in a manner that is very hard to trace.
Way 4: File exchange
One side exports a file, the other imports it. It sounds primitive but remains a reasonable option with very old systems, or with external partners who expose no API.
What keeps it from becoming a disaster: a strictly specified file format, an identifier and timestamp on every file, an archive of processed files, and an alert when a file fails to arrive on schedule.
A quick selection table
| Situation | Choose |
|---|---|
| Stock and receivables — must be exact immediately | API |
| Catalogues and price lists — change a few times a month | Batch sync |
| Data for reporting, no immediacy needed | Overnight batch sync |
| Legacy system with no API, read-only need | Direct database read, read-only |
| External partner with a closed system | File exchange on an agreed format |
The hardest question: who is the source of truth
When two systems hold the same kind of data, sooner or later they will disagree. The question to answer before writing any code: for each kind of data, which system is authoritative?
- Each field has exactly one system permitted to change it; the others read only.
- If both genuinely must be able to change it, there has to be an explicit conflict rule — and every conflict must be logged for a human to review.
- Always run a periodic reconciliation report between the two. Without it, drift accumulates silently for months.
Integration is not hard because of moving data. It is hard because of deciding who gets the final word.
If your business runs several disconnected systems and wants them joined, the system integration and API solution area is where to start — usually the first survey is enough to identify which method fits.
Want to talk specifics?
SealCore surveys at your premises and sends a fixed quote after the first session — including when the conclusion is that you do not need custom software.
