Disconnected Systems: What to Connect First

Disconnected systems hold the same information and have no way of passing it to each other, so a person moves it across by hand. That work is real, it happens every week, and it sits in nobody's job description. This article covers which copying is worth removing, which is cheaper to leave alone, and what an AI system does at the point where a straight integration stops.
We have already listed where your team loses time to manual work (opens in new tab) as a set of areas, and moving data between tools was one line on that list. This article stays on that line, because the decision underneath it is less obvious than it looks. Closing every gap between two systems is not the goal, and some of those gaps are cheaper open.
Why disconnected systems never show up as a cost
Nobody was given the job of moving the data. It happens inside other tasks. Someone exports a list to prepare a report, reshapes two columns so the next tool will accept them, and pastes the result in. On the timesheet that hour is called reporting, and the copying inside it has no name.
The pattern is visible across Europe. Eurostat counts how many companies run ERP software (opens in new tab), which it defines as applications whose purpose is to let information flow across functions such as purchasing, sales, customer relations, finance and human resources. In 2025, 41% of small enterprises in the EU used one, against 89% of large enterprises (opens in new tab). For customer relationship software the figures were 25% and 65%.
Read those numbers as a description of who carries the connection. In a large company, software passes information between functions. In a small one, the connection between sales and finance is frequently a person with two windows open.
Disconnected systems rarely arrive by decision. Tools get bought one at a time, each for a good reason, and none of them is ever asked to speak to the one bought before it.
Four kinds of copying, and they do not cost the same
Each row below is a different reason the same value ends up in two places, and each one fails in its own way once something changes.
What gets copied | What goes wrong | What is worth doing |
|---|---|---|
The same field into two systems | The two versions drift apart and nobody can say which one is current | Connect them and name one side as the source |
Data that has to be reshaped first | The reshaping rule lives in one person's head and leaves with them | Write the rule down before connecting anything |
The same company or product under different names | A match on exact text returns nothing and the record is created twice | Match on meaning rather than on spelling |
A copy that turns into the reference | The spreadsheet becomes the version people trust and the system behind it stops being updated | Decide which system is authoritative, then automate |
Name matching is where most connection projects stall. The first two rows are ordinary engineering: two systems, one agreed field, one direction of travel. The third row is the one that keeps coming back, because the same supplier is registered under a legal name, invoiced under a trading name and saved in the CRM under whatever the salesperson typed in 2023.
What an integration does, and where it stops
An integration moves a field from one system to another once both sides agree what that field is called and what belongs in it. Order number to order number, amount to amount. That part is close to solved, and any competent developer can build it.
It stops at the point where the two systems describe the same thing differently. A product carries an internal code in the warehouse and a commercial name in the shop. A date arrives in one format and is stored in another. A customer exists twice because somebody added a space.
A rule can be written for each of those. The next system, or the next supplier, needs the rule written again, and the list never closes. This is the point where an AI system does something the rule cannot: it compares the incoming value against what has actually been recorded before rather than against a pattern somebody typed in advance, and it returns how sure it is of the match. Above the level of certainty you set, the record is written. Anything under that level stops and waits for a person, who sees the possible matches listed beside the incoming value. A rule offers nothing here, because a rule firing on a wrong match behaves exactly like a rule firing on a right one.
What this looks like in our own systems
We build this for other companies, so treat the next two paragraphs as an interested party describing its own work.
Our invoice system reads a document and writes the result into the accounting software already in use. Which route it takes depends on what that software allows: a direct connection where one exists, a file import where it does not. Neither route required the company to change accounting programs, and that constraint shapes more of these projects than any model choice does.
The wider version of the same idea is AI Business Brain (opens in new tab), which we built for ourselves first. It holds the company context in one place and connects to the tools where the work already happens: CRM, ERP, email, calendar, documents, project boards, chat and finance systems. What changed for our own team is the question people ask. Instead of working out who would know, they ask what the system holds, and the answer arrives with the records it came from.
When copying by hand is the cheaper answer
Not every pair of disconnected systems is worth joining. Three cases, and the third argues against everything above.
A transfer that happens twice a month and takes four minutes is not a project. The hours are small, the risk is small, and a connection built around it costs more to maintain than the copying costs to do.
A system already scheduled for replacement should not be connected to anything. Building an integration into a tool you plan to retire means paying for the same work twice, and the second bill usually arrives during the migration.
The awkward case is the one where the copying is the only review step in the process. Somebody re-reads the figures while moving them, notices that a total looks wrong, and fixes it before it reaches the next system. Remove the copying and that check disappears with it. The honest answer there is to design the check on purpose, because a review that survives only as a side effect of manual work will not survive automation. That is the same reason we wrote that process automation starts after process repair (opens in new tab).
Where to start
Open one task you finished last week and count how many windows the same number was typed into. Then check whether the versions still agree today.
Two windows and no disagreement means the copying is an inconvenience. Three windows and two answers means the copying has already become a data problem, and connecting the systems is the smaller half of the fix. Disconnected systems stay cheap to live with until the versions stop agreeing, which is the moment that count is meant to catch.
Get in touch (opens in new tab) and we will go through one of those flows with you, including the possibility that the honest answer is to leave it as it is.

Justas Česnauskas
CEO | Founder
Builder of things that (almost) think for themselves
Connect on LinkedIn
