In a merger or acquisition, integration is often taken as the default: two organizations, so two systems become one. That assumption costs time, money and attention, and sometimes it costs more than it delivers. Some systems shouldn't be merged. Not because it's technically impossible, but because the result isn't worth the effort it requires.
The question "which systems are better left standing" is therefore not an exception to the integration process. It is a fixed step that comes back with every component, from the CRM to production planning to HR administration.
Merging destroys value in a few recognizable ways.
If the system has no overlap with the rest of the organization, integration only adds risk without creating synergy anywhere. Think of a specialist system that supports one team in a niche the rest of the business doesn't touch.
If the costs of migration outweigh the benefit of having a single system. Data transfer, redesign, training time and the risk of errors during the transition are real costs. Those costs sometimes don't match what is gained in ease of management or license costs.
If the system was just implemented or has just been written off, so that switching requires double capital without the first investment having been earned back.
If merging leads to a compromise in which neither organization gets what it needed, and the operational friction that arises afterward is greater than the friction of two systems existing side by side.
A more detailed elaboration of this trade-off, with the signals that are already visible beforehand, can be found at when integrating destroys value and how you recognize it.
Deliberately leaving something standing is different from not thinking it through. A system you leave separate remains part of the integration decision, only the conclusion "do not merge" follows from that decision. That means agreements are still needed about management, about who is responsible for what, and about how reporting or data traffic between the two systems runs as long as they exist side by side.
The signals that let you see beforehand that something should stay separate are worked out at what you deliberately keep separate and how you see that beforehand. This goes beyond systems alone: it also applies to teams, processes and customer relationships that have their own value as long as they are not absorbed into a larger whole.
To prevent this question from being asked by chance for one system and skipped for another, a fixed decision point works better than separate discussions. For every component — system, process, team — the same question is asked: what does merging deliver, what does it cost, and is there a reason to postpone it or not do it at all.
How that decision list is structured and which criteria consistently recur can be found at how you decide per component whether or not to integrate and how you see that. The outcome of that decision is not always final: something that stays separate now may still be merged later once circumstances change.
With a buy-and-build strategy, the trade-off differs from that of a one-time acquisition. A platform company that integrates multiple acquisitions in succession benefits from repeatable choices: systems that remain separate in one acquisition may also remain separate in the next, so that the pattern becomes predictable instead of every deal generating a new discussion. What that means for your approach can be found at what buy-and-build means for your integration approach. For deal teams that have already drawn up an integration plan before, it is also worth looking at what from that plan can be reused for the next transaction, as described at how you reuse an integration plan.
A deeper overview of which systems in practice more often remain separate, and the signals that go with that, can be found at which systems are better left standing and how you see that.
The generators for the synergy baseline, Day 1 plan and Day 100 plan, together with the integration office for benefit tracking and dependencies, are meant to structure these decisions. They do not deliver a track record and no guarantee of a good outcome. They ensure that the question "should this really be merged" is asked for every component, instead of for a few and forgotten for the rest.
The tool is under construction. Anyone who wants to use it once it becomes available can sign up for the waiting list.
The question of which systems remain separate is often linked to another question: which work in those systems is actually still done manually, and which part of it can be taken over by AI. An integration is a good moment to map that out, since processes are already under review anyway. The work scan from FTE TO AI calculates, per task, which part of the work qualifies for takeover by AI, regardless of whether the underlying systems are merged or continue to exist side by side.
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.