In most sectors, the value of a company lies in assets: buildings, inventory, contracts with a fixed term. In ICT, the value lies largely in people and in the code those people have written and understand. Customers often don't buy a product but a relationship with an account team or an implementation partner. That shifts the balance an integration must pay attention to: where a manufacturing company can direct most of its attention to systems and procurement, an ICT company's center of gravity lies with retention of key staff and with the question of whether customer contracts survive the transition without renegotiation.
That shift is not a matter of degree but of nature. A warehouse can wait for a quiet moment to merge. A developer who wants to leave will be gone within a few weeks, and with him often the knowledge of a system that is documented nowhere. Synergy on paper — a shared platform, a combined sales team — has no value if the people who must execute it have already left before the first step is taken.
In ICT too, integrating is not self-evident. Two software units with overlapping products may, through merging, actually lose customers who chose one of them because of a feature the other lacks. Two engineering teams with a different way of working — different sprint cycles, different codebase conventions, different tools — lose time aligning something that operationally yields no synergy, only friction. The value in a buy-and-build strategy should therefore not automatically be equated with integrating; sometimes the value lies precisely in letting teams that function well continue to operate separately.
The synergy baseline helps to sharpen that question per component: which part of the engineering team, which part of the customer portfolio, which part of the systems. Not as an assumption upfront, but as something that must be demonstrated before it counts as synergy.
The first bottleneck is retention. An earnout or retention bonus for key developers sounds like a detail of the deal structure, but without a concrete Day 1 signal — who stays, under what conditions, and when that is communicated — room arises for uncertainty that leads people to decide for themselves to leave. Waiting until Day 100 to arrange that is in practice often too late.
The second bottleneck is customer communication. ICT customers often have a contract with a cancellation moment or a renewal date, and an acquisition is for them a reason to look at alternatives. Whoever postpones the message to major customers until after closing risks the customer hearing the news through the grapevine and interpreting it differently than intended.
The third bottleneck is technology: merging two tech stacks is rarely a matter of the same week. Some integrations — a shared invoicing module, a central CRM — can be done with limited impact. Others — merging core platforms that customers run on daily — require a longer approach precisely because an error there is immediately visible to the end user. The Day 1 and Day 100 plan serve to make that distinction upfront, rather than discovering it along the way.
The dependency between tasks is a pattern that also occurs in other sectors, only with different nodes. In an acquisition in construction, it is permits and subcontractor relationships that determine what can happen when; in an acquisition in real estate, it is often the structure of management agreements. In ICT it is the combination of people who can leave and customers who can cancel — both faster than a physical process can be adjusted. The integration office records those dependencies so that it is clear which step blocks another step, regardless of the sector in which that node occurs.
In software acquisitions, synergy is often attributed to the dealmaker who came up with the figure, while the operational lead who must deliver on it only joins later. That same tension plays out in financial services and in the energy sector, and the question of who owns a synergy figure should be answered before closing, not after.
The three generators and the integration office build structure: a synergy baseline per component, a Day 1 plan with concrete first steps, a Day 100 plan with dependencies and a decision list for what is and is not integrated. There is no completed engagement being referred to and nothing is promised about the outcome. The instrument asks the questions and organizes the answers; the assessment remains with the deal team.
The tool is under construction. Anyone who wants to use it once it becomes available can sign up for the waiting list.
A synergy baseline and a Day 100 plan consist of a large number of separate tasks: reviewing contracts, comparing customer lists, mapping dependencies. Some of those tasks can largely be automated, others require judgment that cannot be delegated. The work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, so that it becomes clear where time is saved and where human judgment remains necessary.
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.