An order arrives. Somebody types it into the accounting package. Somebody types the customer into the CRM. Somebody updates the stock spreadsheet. Three versions of the same fact, entered by hand, each an opportunity to be slightly wrong.
When systems do not talk to each other, the usual answer is not to replace them. Each one is probably fine at its own job, and replacing a working system to solve a connection problem is an expensive way to acquire a different set of problems. The work is in the gaps between them.
The retyping tax
Worth measuring before deciding anything, because the number is usually larger than the feeling.
Count how many times a single new order, customer or job is entered by a person. Then count the corrections: the invoice raised against a slightly different name, the stock figure that was right yesterday, the customer who exists twice because someone typed a middle initial. Then count the questions that cannot be answered at all, because doing so would mean joining two systems by hand.
That third category is the one people leave out, and it is often the largest. Not knowing which customers are profitable, or which products are actually moving, is a cost even though nobody spends an hour on it.
Which systems can talk to each other, and which cannot
| Situation | Difficulty |
|---|---|
| Both systems are modern products with proper interfaces | Straightforward. Often a connector already exists and the work is configuration rather than building. |
| One is modern, one is older but has a database you can reach | Doable. Read directly, write carefully, and expect to spend the time on understanding the older data model rather than on code. |
| One is a desktop application with files on a shared drive | Awkward but usually possible, by watching for file changes or working with scheduled exports. Fragile, so build in alerting. |
| One is hosted by a supplier who will not give you access | The genuinely hard case. Sometimes there is a reporting export you can schedule. Sometimes the honest answer is that this system has to change before anything else can. |
| One is a spreadsheet | Easy technically and risky in practice, because a person can restructure it at any moment and break the connection silently. |
The fourth row is worth checking first, before planning anything else. A single system nobody can reach determines the shape of the whole project.
Decide which system is the master
This is the decision that matters, and it is not a technical one. It causes more trouble than any integration problem, because it is usually skipped.
For every piece of information that lives in more than one place, one system has to be the one that is right. If a customer's address differs between the CRM and the accounting package, which wins? If stock differs between the shop and the warehouse system, which is true? Without an answer, a connection does not fix inconsistency, it propagates it faster, and now the wrong value spreads everywhere within a minute instead of staying in one place.
- List each type of information: customer details, products and prices, stock, orders, invoices.
- For each, name one system as the master, and say which direction the data flows. Usually one way. Two-way syncing is far harder and should be a deliberate choice rather than an assumption.
- Decide what happens on a conflict, because there will be one. Master wins is a fine answer. Flag it for a human is also fine. Silently pick one is not.
- Say who is allowed to edit what. If the master is the accounting package, editing the address in the CRM should either flow back or be prevented. Anything else confuses people.
- Write it on one page and put it where the team can see it, because they need to know where to make a change.
What breaks, and how you will know
Connections break. Not occasionally, routinely, and a connection that fails silently is worse than no connection because everyone has stopped checking.
- A supplier changes their interface, usually with notice you did not read because it went to a developer who has left.
- Credentials expire, or someone rotates a password without knowing what depends on it.
- Someone adds a required field in one system that the other does not send.
- Unexpected data arrives, a name with an unusual character, a quantity of zero, a date in the wrong format, and the connection stops rather than guessing.
- A rate limit is hit during a busy period, which is exactly when you least want it.
So the specification has to include how you find out. Alerts to a named person rather than an inbox nobody opens. A record of what failed and why, in language an operations lead can read. A way to retry safely, so a rerun does not create every invoice twice. And a plain view of what synced today, so somebody can sanity-check it in ten seconds. Budget for that as part of the work rather than as a nice addition, because it is the difference between a connection you trust and one you check by hand, which was the original problem.
What it costs
| Job | Illustrative cost | Ongoing |
|---|---|---|
| A scheduled export from one system into another, one direction | $1,500 to $6,000 | Almost nothing |
| Two modern systems, an existing connector configured properly | $3,000 to $12,000 | A modest subscription |
| A custom connection between two systems, with error handling and alerts | $8,000 to $30,000 | Hosting, plus attention when something changes |
| Several systems, a central place for the data, reporting on top | $30,000 to $100,000 and up | 15 to 25 per cent of build a year |
Illustrative ranges from the kind of work we quote, not a price list. The first row is the one people skip past, and for a single flow it is frequently the correct answer.
Four shapes a connection can take
Not all connections are the same thing, and knowing which shape you need stops you buying a larger one than the job requires.
| Shape | How it works | Best for |
|---|---|---|
| A scheduled export | One system produces a file on a timetable, another reads it. Old-fashioned, entirely reliable, easy for anyone to debug. | Anything where nightly is soon enough, which is more cases than people admit. |
| A polling connection | Something asks one system every few minutes what has changed, and pushes it to the other. | Most day-to-day business needs. Simple to reason about and to restart after a failure. |
| An event connection | One system announces a change the moment it happens and the other reacts immediately. | When someone is genuinely waiting on the result, such as stock at the point of sale. |
| A central place for the data | Everything flows into one store, and reporting and other systems read from there rather than from each other. | Four or more systems, or when the real goal is reporting across all of them rather than keeping two in step. |
The first two cover the large majority of small-business integration work. The fourth is a different kind of project and should be recognised as one before it is started by accident.
Start with one flow
- Pick the single most retyped thing. Usually new customers or new orders. Not the most interesting one, the most repeated one.
- Connect that, in one direction only. Resist the urge to do everything at once, because the second flow is much easier once the first has taught you what the data actually looks like.
- Run it alongside the manual process for a fortnight, comparing. Tedious, and it is what turns a nervous switchover into an uneventful one.
- Then stop doing it by hand, deliberately, and tell everyone it has stopped.
- Only then add the next flow. Most businesses find that two or three flows remove nearly all the pain, and the rest is not worth automating.
If the retyping is really happening because a spreadsheet is holding the whole process together, signs your spreadsheet has become your business system is the prior question. And if the goal behind all this is a single view of your numbers, what a business dashboard costs explains why connecting the systems is most of that project too. The connecting work itself is data pipelines, and where a small tool is needed to sit between systems, internal tools.
Not for you if
The question that settles the scope: which single piece of information, if it were always right in every system, would remove the most arguments? Connect that one first, and see whether you still want the rest.