A Day 100 plan becomes overloaded when everything that ever needs to be decided gets crammed into the first hundred days. That is a common mistake: every topic feels urgent as long as the deal has just been signed. But not every topic is. The question that too often gets skipped is not "what all needs to happen", but "what can wait, and what does waiting cost".
Delay always has a price, even when that price is small. Running two IT systems side by side costs money per month. An unclear reporting line costs trust within the team. A non-harmonized procurement contract costs missed economies of scale. The question is not whether delay costs something, but whether that cost is currently lower than the cost of forcing a decision right now for which the organization is not yet ready.
That distinction calls for an explicit decision list: what gets integrated now, what gets deliberately postponed, and what may never be merged at all. Without that list, the distinction disappears on its own under the time pressure of the first weeks, and everything automatically becomes "now".
Some categories lend themselves better to postponement than others. Systems that do not directly touch customer contact can often coexist longer than expected. Culture integration at the detail level — visual identity, office layout, internal terminology — rarely needs to be completed within the first hundred days. Secondary supplier contracts can run out on their own timeline instead of being forcibly merged.
What can rarely wait is uncertainty about who decides on what and who is responsible for what. That directly affects the people who have to carry out the integration. See also which decisions typically do belong in the first hundred days for the distinction with what cannot wait.
Before something goes on the "can wait" list, the question should be whether that part needs to be integrated at all. Integration is not a goal in itself; it is a means that sometimes adds value and sometimes destroys it. Merging a system because it "sounds logical", without a concrete benefit to offset it, is not a postponement issue but an integration issue that was never actually asked. Whoever asks this question only after a hundred days may by then have already put months of work into something that could have been better left separate.
A decision to postpone something is only valuable if someone holds onto that decision. Without an owner, "later" naturally shifts to "never discussed" or, conversely, to "doing it now after all because no one stopped it". That calls for a structure in which postponed elements are just as visible as the elements that are included in the Day 100 plan, including a moment at which it is reassessed whether the postponement is still the right choice.
That oversight belongs in the integration office, alongside the tracking of synergy benefits and the monitoring of which dependencies can block the rest of the integration. A postponed element that no one puts back on the agenda is, in practice, an element that has been written off without that decision ever having been made explicit.
Even with a careful decision list, a Day 100 plan sometimes gets stuck: priorities shift, a key person leaves, or a blocking dependency takes longer than anticipated. Then the question is not only what gets shifted, but how that shift happens visibly and in a controlled way rather than silently. That topic is addressed in what to do if the hundred days are not met.
The people who have to carry out the postponement or live with it also deserve attention. Uncertainty about what does and does not proceed is one of the reasons why key employees leave during the uncertain months following an acquisition. An explicit decision list with postponement moments is therefore not only a planning instrument, but also a way to limit that uncertainty.
The three generators — synergy baseline, Day 1 plan, and Day 100 plan — and the integration office are meant to make this trade-off explicit rather than letting it happen implicitly. They structure the question of what needs to happen now, what can wait, and who keeps track of that. They are not a track record and not a guarantee of a good outcome; they are tools that bring the right questions back at the right moment.
The tool is under construction. Those who want to work with it once it becomes available can sign up for the waiting list.
Postponing integration work is immediately also a question about capacity: which part of the work that does go ahead requires people, and which part can be supported by AI so that the organization can manage the first hundred days without becoming overburdened. FTE TO AI calculates per task which part of the work can be taken over by AI, an addition that becomes relevant as soon as it is clear what actually needs to happen within those hundred days.
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.