After the signature comes the assumption that everything must be brought together. Systems, teams, processes, brands — making one whole seems the logical conclusion of a deal. That assumption is not always correct, and the components where it isn't are often recognisable in advance.
Integrating is a choice, not an automatism. For every component — a system, a team, a customer relationship, a product line — the question applies whether merging adds value or costs value. That question is not an exception for the difficult cases. It is the standard question, even for the components that look self-evident.
The reason this goes wrong is usually not unwillingness to look. It's time pressure. A Day 1 plan has to be in place, a synergy case has to add up, and "integrate" is the shortest route to an answer that looks complete on paper. What's missing is a moment where someone records, per component: this we merge, this we leave standing, and this is why.
There are patterns that are visible in advance, not only after the fact. Two systems that fulfil the same function but are built on different logic often cost more in conversion and training time when merged than they yield in ease of management. A team that performs on the basis of speed and short lines loses that characteristic as soon as it is absorbed into a larger, more layered structure. A customer relationship that runs on a specific person or a specific way of working often does not survive an integration in practice, even if it survives in name.
The question when does integrating destroy value deserves a place alongside every synergy calculation, not after it. A synergy case that only counts the yield of merging and not the costs of disintegration — delay, attrition, customer loss — is half a story.
Systems are the component where integrating is most often assumed as a matter of course, and where it most often turns out to be wrong. A system that works well, is embedded in the team that uses it, and gives no acute reason for replacement, does not need to disappear just because it belongs to another entity. The question which systems are better left standing and how do you recognise that in advance belongs in every IT inventory, sometimes resulting in: do nothing, let two systems exist side by side, or decide only a year from now.
The decision to integrate or not also depends on the type of deal. For a platform that grows through multiple acquisitions, the integration pattern differs from that of a single acquisition. What buy-and-build means for your integration approach and how you recognise that is a different question from what a one-off acquisition requires: for a platform, consistency across multiple acquisitions is relevant, and that sometimes actually argues in favour of integrating components that in a one-off deal would be better left standing.
This also touches on the reuse of earlier plans. A platform doing its third or fourth acquisition has already made choices about what was and wasn't merged the previous time. The question how you reuse an integration plan and how you recognise for which components that works determines whether those earlier choices are a starting point or a pitfall — a plan that worked for the previous deal does not automatically work for this one.
Where an integration gets stuck differs by sector. In construction, the bottlenecks are often in project administration, subcontractor relationships and permits tied to a specific entity — see where an integration gets stuck in construction. In the installation sector, it more often concerns service contracts, equipment management and the people who carry the customer relationship in practice — see where an integration gets stuck in the installation sector. Both examples show that the decision list puts different components at the top depending on the sector.
A decision to integrate or not does not become more reliable by putting it in a spreadsheet, but it does become traceable. The synergy baseline, the Day 1 plan and the Day 100 plan are generators that give structure to that decision: recording per component what the assumption is, what it depends on, and when it will be reviewed. The integration office tracks dependencies and keeps the decision list — what is and isn't merged, and why — alongside the benefit tracking, so that an assumption that no longer holds becomes visible before it becomes costly.
This is not a track record. There is no completed track record being referred to, and the tool does not claim that integrating goes better because it is structured. What it does is put the question that would otherwise be skipped, back on the agenda per component.
The tool is under construction. Anyone who wants to use the generators and the integration office once they become available can sign up for the waiting list.
The question of what you merge and what you don't is closely related to another question: what part of the work in a component actually runs on tasks that can be automated, regardless of whether that component ends up with one entity or the other. The work scan of FTE TO AI calculates per task what part of the work can be taken over by AI, providing a different kind of baseline than the integration choice itself — one that shows where capacity becomes available, regardless of how you decide organisationally.
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.