When your business systems do not talk to each other: how to plan an integration that lasts

Most companies acquire their systems one at a time: accounting software first, then an online store, a CRM for sales, and an inventory system for the warehouse. Each works fine on its own; the trouble is that they do not talk to each other. Orders are retyped into the ERP, a daily stock export still fails to reconcile, and one customer appears three different ways in three systems. Eventually someone proposes integrating everything. Integration does solve these problems, but it does not end with buying a tool or connecting an API — done carelessly, it simply replaces a typo made by a person with a wrong value copied automatically into every system. Here is how to plan it, in the order it actually happens, and where it most often goes wrong.

Map the data flows and decide which system is in charge

The usual opening question is "can system A connect to system B?", but the better one comes first: which data needs to move, and from where to where? The most important decision is the system of record — which system is in charge of each kind of data. Product data might be governed by the ERP, customer contact details by the CRM, and payment status by the payment gateway. Leave this undecided and both sides can edit the same field, the systems overwrite each other, and eventually nobody knows which number is right. Once the system of record is set, other systems generally only read that data, and any change goes back to the source. Then write down the following for each data flow:

• What moves, and in which direction: orders, stock, customers or invoices, one way or both. Keep it one-way wherever you can — two-way sync has to resolve conflicting edits made on both sides, which makes it considerably harder to build and maintain.
• Timing: how fast the business really needs it. Stock during a flash sale has to be close to real time; accounting data is usually fine once a day. "Real time if possible" is not a requirement — ask what a fifteen-minute delay would actually cost you.
• Volume and peaks: how many records on a normal day and during a campaign. This decides whether you will hit the other side’s API rate limits.
• Mapping: the same product or customer usually has different codes in each system, so you need a mapping table. Work out in advance how bundles, one-to-many item codes and unit conversions will be handled.
• The cost of getting it wrong: does bad or late data mean one extra phone call, or overselling and incorrect invoices? The higher the cost, the more thorough the checks and reconciliation need to be.

Four ways to connect systems, and what each one trades away

• File exchange (CSV, Excel, scheduled transfers over SFTP): the plainest option, and often underrated. When a system has no API, or once a day is enough, this is the cheapest approach and the easiest to troubleshoot — if something goes wrong, you can open the file and look. The catch is poor timeliness and fragility: a format change breaks it, and someone has to confirm the file was actually produced and actually imported.
• Scheduled API sync: a job asks the other system for changes at regular intervals. It is simple to build, does not depend on the other side notifying you, and covers the needs of most small businesses. The catch is that short intervals burn through your rate limit, long ones are not timely enough, and the other system must be able to return "everything changed since a given time" — otherwise each run has to scan the full data set.
• Webhooks (event notifications): the other system tells you the moment something happens — the best timeliness with no repeated querying. The catch is that you need a receiver that is always online, and notifications can arrive twice, out of order or not at all, so they still need a periodic catch-up job rather than being relied on alone.
• A middle layer (your own integration service, or an iPaaS platform): every system talks only to this layer, and transformation, retries and logging live in one place. Once you have more than three or four systems it saves connecting every pair, and replacing one system only affects the layer. The catch is one more component to operate, which is rarely worth it when only two systems are involved.

Choose by working backwards from the need, not forwards from the technology. If once a day is enough, file exchange or a scheduled sync will do. If you need to react immediately, use webhooks plus a periodic catch-up. If there are many systems and complicated rules, consider a middle layer. Between standard cloud services with simple rules, an automation tool such as n8n or Make is often enough; data flows that involve money, stock or careful reconciliation are better written as an integration service with full logging. If a legacy package has no API at all, ask the vendor about import and export functions or a paid interface first. Treat RPA — software that mimics a person clicking through the screens — as a last resort: it works, but it breaks whenever a screen changes, so it suits a stopgap rather than a long-term design.

Integrations will fail, so decide now what happens when they do

• Make repeats harmless: a retry after a timeout, or a notification delivered twice, can process the same order two times. Give each record a unique ID and have the receiving side check whether it has already been handled, so you do not end up with duplicate orders or stock deducted twice. Engineers call this idempotency, and it is worth asking any developer how they will achieve it.
• Limit retries and give failures somewhere to go: retry temporary errors automatically, with growing intervals. Records that keep failing belong in a review queue with an alert to whoever is responsible — never silently dropped, and never blocking everything behind them.
• Reconcile regularly: even a good sync can lose records, so compare counts and totals on both sides on a schedule — daily order counts and revenue, for instance — and raise an alert on any difference. Reconciliation is the last line of defence and the step most often skipped.
• Keep a trail: when each record arrived, what it was transformed into and whether the write succeeded should all be traceable. When someone asks why an order never reached the ERP, nobody should have to dig through code and the other vendor’s back office. Keep sensitive values such as card numbers and passwords out of those logs.
• Make it possible to replay: if the other system is down for a day, you need to reprocess that period once it is back. Decide at design time how to rerun a time range, and make sure a rerun cannot overwrite newer data with older values.

The mistakes that come up most often

• Reading and writing directly to another system’s database: it looks like the quickest route, but table structures can change with any upgrade, you bypass the system’s own business logic, and when bad data gets in even the vendor may refuse to help — some licences forbid it outright. Use the official interface wherever one exists.
• Wiring every pair of systems directly: the easiest start, but with more systems it becomes a web — replacing one means changing several connections, and nobody can describe how the data really flows. As connections multiply, draw the full picture and consider consolidating.
• Syncing before cleaning the data: duplicate customers and inconsistent item codes stop being one system’s problem and spread to all of them. Clean up and build the mapping tables first.
• Not checking the API’s real terms before signing: "we have an API" does not mean it is enough. Ask whether access costs extra, whether there is a test environment, whether the documentation covers the fields you need, what the rate limits are and how long old versions stay supported. Plenty of APIs turn out to be read-only, or to lack the one field that matters most.
• Testing against production: integration tests really do create orders, send emails and deduct stock. If the other side has no test environment, use separate test accounts and data, limit the scope, and open up gradually rather than all at once.
• API keys tied to a personal account, with full permissions: when that employee leaves and the account is disabled, the integration stops; if the key leaks, the whole system is exposed. Use a dedicated service account, grant only what is needed, and rotate keys regularly.
• Nobody owning it after launch: external APIs change, certificates and keys expire, and company processes evolve. Agree who receives the alerts, who fixes things and who leads the investigation across vendors — otherwise, when the integration breaks, each vendor will say the problem is on the other side.

Integration does not have to happen all at once. Pick the one data flow that hurts most and goes wrong most often, settle its system of record and mapping rules, get it running reliably, and move on to the next once the reconciliation figures agree — far safer than planning a company-wide integration up front. The order of reasoning stays the same: decide which system is in charge, let timing pick the method, and only then choose the tools. If your systems have drifted apart, or you are unsure whether your existing software can be connected at all, Floatstone Digital can map your data flows, assess the options, and handle the development and ongoing operations.