A deal team that has integrated an acquisition before often has a plan lying around. A Day 1 checklist, a list of synergy categories, a communication schedule. The temptation is great to pull that document out of the drawer, change the names and numbers, and move on. That saves time. It also saves thinking, and that is exactly the problem.
An integration plan is not a template for an organization, it is the outcome of choices made for a different combination of companies. Which systems merge, which teams combine, which customer relationships remain separate — those choices depended on what the previous two companies were, not on what these two companies are. Reusing a plan without re-testing those underlying choices means you are adopting structure that was built for a different situation.
The risk is not in the form. Phasing, a benefit tracker, a list of dependencies — those parts are often perfectly reusable. The risk lies in the content that travels along unnoticed: the assumption that department X is always merged, that system Y is always phased out, that culture integration is always approached the same way. Those assumptions are not neutral. They are precedent, and precedent feels like evidence when it is not.
Three things generally travel well from one process to another:
These components are method, not outcome. They tell you how to arrive at an answer, not what the answer is. That distinction is the core of responsible reuse: adopting the process, not the conclusions.
It becomes risky the moment a previous plan skips the question itself. If the previous process determined that two sales teams should merge, and that is automatically carried over because "that's just how it works," the chance that it also holds true this time depends on coincidence, not on analysis. You can read more about when merging destroys value and how you recognize it on another page, but the recurring question comes back here: might this component have been better left separate.
This applies strongly to systems. An IT migration that made sense in the previous deal — because the acquired company had an outdated platform — is not automatically sensible for a company with a system that was just renewed and is functioning well. Which systems you are better off leaving as they are, and how you can tell, is a separate consideration per situation, not a rule you carry over from the previous deal.
Organizational structure is also vulnerable to blind reuse. If the previous plan determined that finance departments always merge, that automatism erases the question of whether that also holds true here. In a buy-and-build strategy, where a platform repeatedly adds companies, the temptation to run a single template is even greater — and the necessity to look afresh at each component even more urgent. What a buy-and-build approach requires from your integration strategy, and how you can tell, therefore deserves its own consideration per acquisition, not one recurring plan.
A workable approach is to use the previous plan as a checklist of questions you need to ask again, not as a list of answers that are already fixed. For every component that was integrated in the previous plan, you ask again whether that also applies here. For every component that remained separate, you ask yourself whether that reason also applies here. How you structure that decision per component — integrate or not, and based on which criteria — ultimately determines more about the result than how quickly the plan is put on paper. See also how you build up that decision per component and how you can recognize it: how you decide per component whether to integrate or not.
What deliberately remains separate deserves as much attention in the reused plan as what is merged. A plan that only contains integration steps and says nothing about what is explicitly not merged is missing half the decision. Making visible in advance what remains separate and why prevents that choice from later being explained away as a mistake. More on that: what you deliberately leave separate and how you record that in advance.
The three generators and the integration office of mergerintegration.net are built on this distinction: structure that travels along, not conclusions that quietly travel along. A synergy baseline, a Day 1 plan and a Day 100 plan are rebuilt for each situation from the same questions, with a benefit tracker and a decision list that force an answer for each component. This is a tool that structures, not experience that guarantees — the tool is under construction and anyone who wants to use it can sign up for the waiting list.
An integration plan is about who does which work, which departments merge and which processes continue to exist. Underneath that question lies a more precise question: how much of the work that will be done together or separately going forward is actually task-based work that can be automated. The work scan from FTE TO AI calculates, per task, what portion of it can be taken over by AI, thereby giving a numerical basis to a choice that would otherwise rest on assumption — precisely the risk that also lurks in reused integration plans.
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.