An acquisition is signed with the assumption that merging creates value. That assumption is rarely tested out loud. Integrating feels like the logical next step, and the question of whether it should happen at all fades from view along the way. That is where value disappears: not in a poorly executed integration, but in an integration that was never up for discussion.
The first sign that integrating is going to destroy value is the speed with which the decision is made to merge something. Systems, teams, or customer relationships are placed under the acquiring party because that is the habit, not because there is a justification stating why that strengthens the value of the deal. If no one can explain why a part must integrate, other than that it "belongs there," that is the moment to stop and ask the question again. That question — whether or not to integrate, and based on what logic — should be asked for every part, not only for the parts that already look doubtful.
A synergy baseline is not just a sum of expected benefits. It is also the instrument with which you see which synergy rests on an assumption that does not hold. If the justification for an item is missing, or if that item only exists because a comparable deal once produced that synergy, that is a sign. Benefit tracking on a deal that is already running makes visible when a synergy falls away or is delayed — and that is exactly the moment to ask whether the underlying integration step is still the right one, or whether sticking to the plan costs more than it delivers.
The parts where integrating destroys value fastest are the parts that are hardest to reverse. A customer relationship built on a specific way of working does not always tolerate a switch to the acquiring party's system or process. Cultural differences that are ignored because the organizational structure simply has to be merged lead to the departure of the people who carried the customer knowledge. More on what you deliberately keep separate and how you recognize that in advance helps to make this distinction before the integration has started, not after the first customers have left.
A common form of value destruction is merging systems because one IT environment sounds tidier than two. If a system at the acquired party functions well, has a team that manages it, and there is no demonstrable reason to replace it, migration is a cost item without a clear return. Which systems you would do better to leave as they are and how you see that in advance is about exactly that distinction: not every system that can integrate should integrate.
The question of whether something should integrate should not only be asked for the parts that stand out. It should be asked for every part, systematically, with the same criteria. That is what a decision list is for: a fixed overview of what is and is not merged, with the justification included, so that "we didn't think it through properly" cannot be an explanation afterwards. How you decide per component whether or not to integrate and how you see that in advance discusses how that list is built and which considerations play a role in it.
For a platform built through repeated acquisitions, the risk of value destruction is different than for a one-off deal. What integrated during the first acquisition does not automatically need to receive the same treatment at the third. Every addition requires its own assessment, even if the platform has already developed a fixed approach. What buy-and-build means for your integration approach and how you recognize that in advance describes why repetition is not the same as a fixed blueprint that fits everywhere.
The generators for the synergy baseline, Day 1 plan, and Day 100 plan are tools to make this consideration explicit, not to remove it. They structure the question of what dependencies exist, what the assumptions are behind a synergy item, and what the consequence is if a part is not merged after all. The tool does not provide an answer to the question of whether integrating creates value in your situation; it provides the structure with which you can answer that question yourself, per component.
The tool for these generators and the integration office is under construction. Anyone who wants to work with this as soon as it becomes available can sign up for the waitlist.
Before you can determine when integrating destroys value, it is good to know where an integration process in practice gets stuck during its construction — where an integration gets stuck during construction describes those bottlenecks. And for a platform that acquires more often, it is worth looking at how earlier plans can be reused without the critical review disappearing for each new deal: how you reuse an integration plan and how you see that in advance.
Where merging is not the right choice, the question remains what then happens to the work that both organizations currently carry out separately. That is a different question from integrating or not: it is about how much of that work, merged or not, can be taken over by AI. The work scan from FTE TO AI calculates per task which part of the work qualifies for that, regardless of what the organizational structure looks like after the deal.
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.