Consolidate your systems, or integrate them?
The licenses are the smallest number in this decision. The cost that decides it is the time people spend moving figures between systems and checking which one to believe.
In short
Consolidation replaces overlapping tools with one that does more. Integration keeps them and makes them talk. Consolidation is cheaper to run and far more expensive to reach, and it fails when the single tool is worse at the thing that matters most. Integration is fast and accumulates a maintenance bill nobody owns. The decision usually turns on whether the overlap is real, or whether two teams simply want different things.
What we take on
Consolidate
Replace several overlapping tools with one that covers enough of what they each did. Cheaper to run and simpler to explain. Expensive to reach, and it dies on the one workflow the survivor cannot do.
Integrate
Keep the tools and make them exchange data. Fast, reversible in an afternoon, and it quietly accumulates a maintenance bill that nobody has been assigned.
The overlap that is not real
Two teams wanting different things often looks like duplication. Before either option, check whether the tools genuinely do the same job or whether one team simply lost an argument.
The migration nobody budgets for
The license is the small number. The cost is data cleaning, retraining, the parallel run and the quarter where both systems are live. Budget for the quarter, not the license.
The integration nobody owns
A connection with no named owner fails silently and stays failed until somebody notices a number is stale. Assign it before it is built, along with how anyone finds out it has stopped.
Deciding the source of truth first
Where the same figure differs between systems, neither option fixes it. Naming which system is authoritative for each number is days of work and it changes which option you then need.
Why the license total is the wrong place to decide from
The question usually arrives as a cost question. Somebody totals the licenses, notices three tools that appear to do the same thing, and asks why. That is a reasonable place to start and a bad place to decide from, because the licenses are the smallest number in the whole calculation.
The real cost is the moving. People exporting from one system and pasting into another, reconciling at month end, and checking which of two figures to believe. That work is invisible because it never produces an artefact, and it is usually larger than the license line by a wide margin.
Consolidation is right more often than people expect above about five systems, because the number of connections between tools grows faster than the number of tools. It is wrong more often than people expect at two or three, where you are trading several good tools for one adequate one and calling it simplification.
The failure mode of consolidation is specific and predictable. Somewhere in the business one team depends on a feature the surviving tool does not have. It is discovered late, a workaround is built, and the workaround becomes a second system nobody counted. Find that team before signing, not after.
The failure mode of integration is quieter. The connection works, nobody owns it, and eighteen months later a number is silently stale because an API changed. Integration is genuinely cheap to build and is not free to keep, and the keeping is the part that goes unassigned.
And where the same number differs between systems today, neither option is the answer yet. That is a definitions problem wearing a tooling costume. Decide which system is authoritative for each figure, in writing, and a surprising amount of the pressure to do either project goes away.
Seven signals, and what each one points at
None of these decides it alone. The first row decides more of it than the other six together, because a source of truth problem survives both options and gets blamed on whichever one you chose.
| Signal in your situation | Consolidate | Integrate |
|---|---|---|
| The same number differs between systems | Only after you decide which system is authoritative. Consolidating first just moves the argument. | Same condition. Pick the source of truth before connecting anything, or you automate the disagreement. |
| Five or more tools hold part of one picture | Usually right. Past four, the integration surface grows faster than the value. | Gets expensive quickly. Every new tool multiplies the connections rather than adding one. |
| Two or three tools, each strong at its job | Rarely worth it. You trade three good tools for one adequate one. | Usually right, and often a single connection is the whole project. |
| A team would lose a feature they depend on | This is the failure mode. Consolidation dies on the one workflow the new tool cannot do. | Keeps the feature. This is the case integration exists for. |
| Nobody can name who owns the connection | Removes the question by removing the connection. | Do not integrate until somebody owns it. Unowned integrations fail quietly and stay failed. |
| Per-seat cost across duplicate tools is painful | The clearest financial case, and the easiest one to measure before deciding. | Does nothing about it. Integration does not reduce seats. |
| A platform migration is already underway | Fold it in. Two migrations at once is one migration with better odds than doing them a year apart. | Wait. Integrating into something you are about to replace is work with a known expiry date. |
Where the table splits, the tie-break is which option you can reverse. Integration is reversible in an afternoon. A migration is not reversible at all once the old contract lapses.
What is the overlap actually costing you?
Four answers. It prices the moving-data tax you are already paying and says which of the two options your situation actually points at, including when the answer is neither.
How to use it, about a minute
- Count the systems holding part of the same pictureCount anything somebody checks to answer the same question, including a spreadsheet.
- Add the hours a week spent moving data between themRekeying, exporting, reconciling and working out which one is right. That figure times the loaded rate is what doing nothing already costs.
- Say honestly how often the same number differsIf the answer is constantly, the tool returns neither yet, because a source of truth problem survives both a migration and an integration.
Count anything somebody checks to answer the same question.
Rekeying, exporting, reconciling, and checking which one is right.
The moving-data tax, a year
0
What your answers point at
Answer the four
A second opinion
Want this checked before anybody signs a contract?
Send it over and you get back which of the two a situation shaped like yours usually needs, the question to settle before either, and what the first two weeks would look like. Your numbers travel with it, so there is nothing to explain twice.
Goes to one inbox.
What this usually leads to
Both answers end in the same place: somebody has to own what moves between the systems. Process automation builds and owns that connection, and data and reporting settles which number wins when two systems disagree, which is the part that survives either decision.
Questions we get
We have four tools and they mostly agree. What now?
Integrate, and name who owns the connection on the day it is built. Four is under the line where consolidation usually pays, and tools that agree are telling you the definitions underneath them are already sound, which is the expensive part to fix.
Revisit it if you pass five, or if a renewal makes the seat maths change sharply.
The vendor says migration takes six weeks. Is that realistic?
The technical move often is. The six weeks rarely includes data cleaning, retraining, the parallel run, or the tail of edge cases that surface once real volume goes through it.
A useful test: ask what happens in week seven if something is wrong, and whether the old system is still available. If the answer is that the contract has lapsed, the plan has no reverse gear.
Can we do both, integrate now and consolidate later?
Often yes, and it is underrated. A connection buys time and costs little, and it makes the later migration easier because it forces you to write down what actually moves between the systems.
The condition is honesty about the interim. Temporary integrations become permanent when nobody sets a date to revisit them.
Our teams each want to keep their own tool. Is that just politics?
Sometimes, and sometimes it is the most important information in the room. A team defending a tool usually has one workflow that only that tool does well, and that workflow is exactly what a consolidation breaks.
Ask each team for the single thing they would lose. If the answers are vague, it is preference. If one is specific and load bearing, you have found the constraint.
How do we work out the real cost of the overlap?
Count the hours, not the licenses. Time how long a person actually spends each week exporting, rekeying, reconciling and checking, then multiply by a loaded rate. The tool above does that.
Then add the decisions delayed because two numbers disagreed. That one is harder to quantify and it is often the larger figure.
Does AI change this decision?
At the margins. A model can read messy output from one system and put it into another, which lowers the cost of connecting things that were never designed to connect.
It does not change the underlying question, and it makes the source of truth problem worse rather than better, because a probabilistic step between two systems that already disagree adds a third version of the number.
What if the systems are fine and the process is the problem?
That is the most common finding, and it is why the source of truth question comes first. Two systems disagreeing is usually two teams defining something differently, not two databases being wrong.
Where that is the case, neither project is needed. Writing down what each figure means, with a named owner, is days of work and removes the pressure entirely.
Do you have a preferred stack?
No, and that is deliberate. Recommending the same stack regardless of situation is how you end up with a migration that solves the consultant problem rather than yours.
The recommendation follows the shape of the work and what your team already knows how to run without help.
Who should own this decision internally?
Whoever owns the outcome the systems serve, not whoever owns the systems. IT can tell you what is possible and what it costs. It cannot tell you which workflow the business cannot lose.
Where those are different people, get them in the same room before a contract is signed rather than after.
What does the first two weeks look like?
Listing every system, what each is authoritative for, and where the same figure appears twice. Then watching the moving: who exports what, when, and what they do when the two numbers differ.
The output is a map, the real cost of the overlap, and a recommendation with the reason attached. Frequently the recommendation is smaller than what was being contemplated.
More in the guides and every answer in one place.
Shaheer Shaikh, operations lead at LARVOL, a San Francisco AI company working with global pharma on clinical trial data and model benchmarking. Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. More about the firm
Read next
The decision next to this one, and the work either answer turns into.