A post-merger integration plan can contain hundreds of tasks and still leave the most consequential questions unanswered. Who owns the customer relationship? Which product will receive investment? Who can approve an exception? What should the combined business actually do differently?
Those decisions shape the integration work. I would put them near the front of the 100-day plan, where the CEO, sponsor, and management team can resolve them.
My career has included acquisition integration and operating leadership across commerce and technology businesses. The recurring challenge is getting people, systems, and commercial commitments to support the same operating model while the company continues serving customers.
Start with the reason for the acquisition
Describe the value the transaction is expected to create. That could involve distribution, product capability, operating efficiency, customer access, or a platform for further acquisitions. Each thesis implies different integration priorities.
If commercial independence protects the acquired company's value, moving everything into a common system may be premature. If the thesis depends on cross-selling, the customer ownership and compensation decisions cannot wait until after the systems project.
Translate each expected benefit into a working assumption, an owner, and evidence. A benefit that cannot be described operationally will be difficult to deliver or measure.
Decide what to integrate, preserve, and defer
Treat integration as a set of deliberate choices. Some controls require early alignment, such as essential financial reporting and access to critical systems. Other areas may need to remain independent while the team learns how the acquired business works.
For a software acquisition, review product overlap, customer commitments, support arrangements, architecture, and release processes before deciding on a combined roadmap. Understand which people hold knowledge that the business cannot afford to lose.
Record deferred decisions with a reason and a review point. Otherwise, temporary arrangements can quietly become permanent complexity.
Build the plan around decisions and dependencies
The first 30 days should establish operating continuity, decision rights, and the information needed to make priority choices. Days 31-60 can resolve the target model and test the most important changes. Days 61-100 should move approved work into a repeatable operating cadence. The actual sequence depends on the deal and business.
A useful workstream record contains the decision required, its owner, the evidence needed, the dependent tasks, and the cost of delay. It also identifies who can resolve a disagreement.
Consider a hypothetical shared account. If two sales teams are expected to cross-sell but nobody owns the relationship or decides how revenue credit works, the CRM integration will not resolve the conflict. The commercial decision has to come first.
Measure benefits alongside disruption
Track the intended benefits, implementation costs, and operating disruption together. A reduction in vendor expense means less if the migration creates customer losses or a backlog that requires outside help.
Finance should distinguish run-rate estimates from benefits already realized. A contracted expense reduction, an eliminated duplicate process, and a forecast cross-sell opportunity belong in separate categories. Avoid counting the same benefit in both the acquired business and the platform.
Monitor customer retention, service performance, key-person risk, and delivery commitments during the transition. Those measures help the leadership team see whether integration is damaging the asset it was meant to improve.
Use one forum to resolve cross-functional issues
Integration problems rarely respect the organization chart. A product choice can affect sales, finance, engineering, and support. Give the team a regular forum with the people who can make the decision, rather than several status meetings that send the issue in circles.
The 100-day plan should leave the combined business with clearer ownership and a workable way to keep improving. Completed tasks matter, but the stronger test is whether the operating model can deliver the reason the acquisition was made.
Related reading: SaaS sprawl and operating risk and An operating diagnostic.