Integrating is a choice, not a reflex. In every merger or acquisition, the assumption is ready-made that combining creates synergy. That assumption often does not hold for every part. Systems, teams, customer relationships and processes that function better apart than together, stay apart. The question is not whether you can integrate, but whether integration at that specific point adds value or destroys it.
There is a tendency to see integration as the complete outcome, and not integrating something as an unfinished process. That is a mistaken picture. Two customer systems that both work well for their own segment do not need to be merged just because merging fits a merger. A brand with its own positioning can continue to exist alongside the acquiring brand as long as that distinction has value for customers. Keeping something separate is then not a compromise, it is the outcome of a deliberation that should lead to a decision just as much as integrating does.
There are a number of recognizable situations in which merging destroys value rather than adding it:
None of these signals is absolute. They are a reason to ask the question, not a fixed answer.
With every part of an integration, the same question applies: should this actually be combined? That is not an exception you raise occasionally in doubtful cases, it is a standard step in the assessment of every part — from IT systems to HR policy to customer communication. A synergy baseline that does not explicitly take this into account counts potential benefits without weighing the counterpart: what does it cost in speed, relationship or quality to merge something that could also have kept working separately.
This deliberation should not arise by chance during execution. It should be structured in advance, with a fixed set of criteria per component. How that assessment looks per component is described at how do you decide per component whether or not to integrate and how do you recognize that in advance.
In a buy-and-build strategy, where multiple acquisitions land in a platform one after another, the question of what stays separate is even more pressing. Every new acquisition that is fully integrated into the existing platform loses the distinctiveness that once gave that acquisition its value. At the same time, keeping too much separate can lead to a collection of loose parts without platform advantage. What this means for the approach to successive acquisitions is explained at what does buy-and-build mean for your integration approach and how do you recognize that.
The decision to keep something separate should get an explicit place in the Day 1 plan and the Day 100 plan, not as a footnote but as a decision with an owner and a reason. Without that documentation, there is a risk that a later project will still try to merge what was previously deliberately kept separate, without knowing the original consideration. An integration office that maintains this decision log prevents today's work from being redone or undone tomorrow.
This decision log also becomes relevant for a subsequent acquisition. A plan drawn up earlier, including the components that were kept separate at the time, is not simply a template for the next transaction — the context always differs. How an integration plan can be reused without ignoring that context is explained at how do you reuse an integration plan and how do you recognize that in advance.
The deliberation between merging and keeping separate plays out differently per sector. In construction, the complexity often lies with project-bound systems and subcontractor relationships that cannot simply be centralized; see where does an integration get stuck in construction. In the installation sector, service contracts and technical certifications play a similar role; see where does an integration get stuck in the installation sector.
The question of what stays separate and what is combined ultimately touches the work itself: which tasks in the organizations coming together overlap, and which continue to function separately. For those who want to look at that level, the work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, regardless of whether that work will eventually land in a merged team or in a component that deliberately remains separate.
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.