An acquisition has been signed, and the assumption that often follows is that merging is the logical next step. That is not always the case. Integrating costs time, attention and money, and it does not automatically produce something. For every component — a team, a system, a customer relationship, a brand — the question is whether merging actually adds value, or whether it mainly adds risk to something that was functioning well on its own. That question is not an exception you ask in cases of doubt. It is the standing question, asked again for every component.
There are a number of situations in which merging costs more often than it delivers.
When two systems each work well for their own user group, and the only reason to merge them is consolidation on paper, you pay the migration costs and the disruption without the operation improving. Which systems those are depends on usage, technical debt and how intertwined they are with other processes — not on a fixed rule that one system is always better than two.
When a team derives its value from a culture, a way of working or a customer relationship that does not survive in a larger structure, integration can remove precisely the thing for which the acquisition was made. This is particularly relevant for acquisitions where talent or customer loyalty was the core of the value, more so than scale or systems.
When two brands have each built their own positioning and the target audiences show little overlap, merging can create confusion without a new advantage emerging. The same applies to two customer portfolios that, while in the same sector, are served through different channels and with different expectations.
And when an integration is carried out because it "belongs" to a merger process, without a concrete synergy standing opposite it, the integration itself is the risk, not the absence of it.
How you make that distinction per component depends on the type of asset, the degree of dependency with other parts of the organization and what happens if you do nothing. How you decide per component whether or not to integrate describes that trade-off as a recurring decision point, not as a one-time choice at the start.
There is a difference between forgetting to integrate something and deliberately keeping it separate. The first is a gap in execution. The second is a decision with a reason behind it — a reason that can be recorded and tested at the moment the situation changes.
That distinction is also why what you deliberately keep separate deserves its own place alongside the Day 1 and Day 100 plan. What is not merged does not disappear from view; it is described with the same precision as what is integrated, including the condition under which that decision would ever be reconsidered.
This plays out strongly with systems. Not every platform, database or tool needs to disappear as soon as there is an acquisition. Which systems you would do better to leave as they are addresses the question of when a system functions better if it keeps running as it runs, and when the dependencies surrounding it in fact make integration unavoidable.
What destroys value in one acquisition can be exactly the right move in another. A strategy aimed at buy-and-build calls for a different trade-off than a one-time acquisition mainly intended as scaling up. With buy-and-build, the emphasis is more often on repeatability: what can be reused in the next acquisition, and what must instead be reconsidered each time because the situation differs. What buy-and-build means for your integration approach addresses that difference, and how an integration strategy that is revised at the second or third acquisition can destroy value just as much as a strategy that was rolled out too quickly at the first.
Anyone who has done an integration before faces the question of whether that plan is reusable for the next one. How an integration plan can be reused describes where that is possible, and where a new plan is needed because circumstances differ too much to simply repeat a template.
The signals that point to value destruction in advance are not always the same as the signals that become visible afterward. What indicates that integrating is destroying value addresses those indicators, so that an integration can be adjusted before the damage becomes definitive.
The generators for the synergy baseline, Day 1 plan and Day 100 plan, and the integration office for benefit tracking, dependencies and the decision list, are meant to structure this trade-off — not to make it for you. There is no completed integration process that this tooling refers to; it asks the question over and over again, for every component, and records what was decided and why.
The tool is under construction. Anyone who wants to work with it can join the waiting list and will be kept informed once it becomes available.
The question of which part of an integration process requires merging is connected to a broader question: which part of the work itself should actually remain human work. FTE TO AI's work scan calculates, per task, which part of the work can be taken over by AI, and that outcome can factor into the decision of whether a team, a process or a system is merged after an acquisition or not.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.