Integration is often treated as the default route after a deal: two organizations, one system, one process, one culture. That assumption costs money in places nobody looks anymore. Some parts should stay separate, not because integrating is too much effort, but because merging in that spot removes value instead of adding it.
In a synergy baseline, a Day 1 plan or a Day 100 plan, the emphasis is often on what needs to happen. Just as important is the question of whether the part should be integrated at all. That is not an exception question you ask once for doubtful cases. It is a standard step, for every system, every team, every process. How you decide per part whether or not to integrate depends on what the part delivers as long as it stays as it is, against what integration costs in time, risk and the attention of people who also have other things to do.
A CRM that has been running for years, set up to match the working method of one team, often contains more operational knowledge than is written down anywhere. Migrating to a shared system then delivers a cleaner architecture, but also a period of reduced effectiveness for the team that most needs to keep performing. Which systems you are better off leaving as they are is a question that stands apart from what is technically possible. Technology rarely stands in the way of integration. The question is whether the return outweighs the disruption, and that answer differs per system and per team.
Within a buy-and-build strategy, remaining separate is often not a shortcoming but the starting point. A platform that adds successive acquisitions to itself benefits from the recognizability and speed of the individual parts, not from one uniform structure that has to be adjusted again with every new deal. What buy-and-build means for your integration approach is therefore a different question than with a single acquisition. There, the standard lies in what works for the next addition, not in what looks tidiest on an org chart right now.
There are a few recognizable signals. A team that runs on its own way of working that does not fit the shared process loses speed as soon as that way of working disappears. A customer relationship that rests on the name or the person of the acquired party can suffer damage as soon as that name disappears into a joint brand. A product line that has a different margin or risk profile than the rest of the organization becomes invisible in shared reporting and therefore ends up under-managed. When integrating destroys value and how you recognize it describes this type of pattern, not as an exception but as a fixed part of every integration assessment.
The easy mistake is discovering this only afterward, when a customer's revenue declines or the team has lost its best people. That is too late. The signals are usually already present beforehand: dependence on one person, a customer relationship without a transferable structure, a system that contains processes that are not recorded anywhere else. What you deliberately keep separate and how you see that in advance helps to recognize these signals in time, before an integration plan writes them off as something that just still needs to happen.
The decision to keep something separate is not a one-time judgment. What stays separate today may well be ready for integration in a year, and conversely, a part that is being merged now might in hindsight have been better off waiting. How you reuse an integration plan is therefore relevant, even when the first version of the plan largely consists of decisions not to do things. The structure of the plan — the decision list, the dependencies, the benefit tracking — remains usable as an assessment framework, even long after the first hundred days.
The generators and the integration office of mergerintegration.net structure these considerations: which parts are on the decision list, which dependencies arise if you do or do not merge something, and how you track whether an expected synergy actually occurs. It is a tool that organizes the question, not a party that says, based on a track record, what the right choice is in your case. That choice remains with the deal team or the operating partner who knows the organization.
The tool is still under construction. Anyone who wants to use it as soon as it becomes available can sign up for the waiting list.
What stays separate often means that people there continue to do their work as they did before. Precisely then it is important to know how much of that work consists of repeatable tasks and how much consists of something that cannot simply be automated or transferred. The work scan of FTE TO AI calculates per task which part of the work can be taken over by AI, regardless of whether a team or system is further integrated or deliberately kept 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.