Post-merger integration is the work of combining an acquired company's product, systems, teams, and processes with the acquirer's after a deal closes. As of August 2026, having led product through eight of these from inside the organization, I think integration damages more good products than any other decision after close — and almost always through choices that were entirely rational when they were made. Nobody wrecks an acquisition on purpose. They consolidate a tool, align a roadmap, standardise a deployment process, and eighteen months later the thing they bought is still running and no longer getting better.
What is post-merger integration?
Post-merger integration is the work of combining an acquired company's product, systems, teams, and processes with the acquirer's after a deal closes. It covers consolidating infrastructure and tooling, merging roadmaps and reporting lines, and it is where most of the value an acquisition was supposed to create is either realised or lost.
It is also the stage with the least diligence attached to it. Enormous effort goes into deciding whether to buy. Comparatively little goes into deciding what to do on the Monday after, and the second decision has more effect on the outcome than the first.
Why does integration damage products that were working?
Because consolidation usually removes the mechanism that made the product good, not the product itself. Small teams decide fast because the whole system fits in a few heads and nobody needs permission. Integration replaces that with process that is correct, defensible, and slower. The product does not break; it stops improving at the rate that made it worth buying.
This is the part that is genuinely hard to see coming, because every individual decision survives scrutiny. Standardising on one CI pipeline is defensible. Moving the acquired team onto the acquirer's release calendar is defensible. Requiring architecture review for changes above a certain size is defensible. Each one adds a small amount of latency and removes a small amount of autonomy, and none of them is the decision that did the damage.
The damage is cumulative and nobody owns it. That is a structural problem, not a failure of judgment.
What should an M&A integration playbook contain?
A list of what will be consolidated, what will be left alone, and the reason for each — written before close, when the answer is still a judgment rather than a reaction. Most playbooks are inventories of systems. The useful part is the second column: what made this product valuable, and does consolidating this particular thing preserve or destroy that.
Here is the frame I actually use:
| Layer | Default | Why |
|---|---|---|
| Billing, identity, HR, procurement | Consolidate | Nobody bought a company for its expense reporting. Real cost, no differentiation. |
| Security and compliance tooling | Consolidate | In a regulated environment this is not optional, and the acquired team usually knows it. |
| Observability and CI | Case by case | Cheap to consolidate, and the first place latency creeps in unnoticed. |
| Deployment cadence | Leave alone | Almost always part of why the product was good. |
| Roadmap and prioritisation | Leave alone, longest | The moment this merges, the acquired product competes for attention against things with bigger numbers. |
| Who can talk to a customer | Leave alone | Proximity to the customer is frequently the entire advantage. |
The column that matters is the third one. A playbook without stated reasons is a list, and lists get executed by people who were not in the room when the judgment was made.
When is consolidation genuinely worth it?
When the thing being consolidated is genuinely undifferentiated. Nobody bought a company for its expense reporting. Consolidation goes wrong when it reaches the layers where the advantage actually lived: deployment cadence, who can talk to a customer, and how a decision gets made.
The test I apply is narrow and it works: name the mechanism. Not the feature, not the team — the mechanism by which this product got good. If you cannot say it in a sentence, you are not ready to decide what to integrate, because you cannot tell which consolidations threaten it.
Sometimes the mechanism is a person who answers support tickets personally. Sometimes it is a deployment process nobody would approve on paper. Sometimes it is that the whole system is small enough for one engineer to reason about end to end, which means the honest integration plan is do not add to it.
How do you know integration is going wrong?
Watch the decision latency, not the milestone tracker. If a change that used to take a day now takes three weeks and two approvals, the integration is succeeding on its own terms and failing on the reason for the acquisition. That signal appears months before it shows up in revenue, and almost nobody measures it.
Integration programmes report on completion — systems migrated, teams onboarded, tools retired. Those are all real and all beside the point. The number that predicts whether the acquisition worked is how long it takes the acquired product to make a change, and it is trivially measurable from the moment of close if anyone thinks to start.
This is the same reversibility test I use everywhere else: a decision that is cheap to undo deserves less ceremony, and one that is expensive to undo deserves more. Most integration decisions are quietly one-way. Once a team is on the shared release train, getting them off it is a political act rather than a technical one.
This is stage six of the seven in the diligence frame. It is the one that runs longest, receives the least scrutiny, and does the most damage — and unlike the earlier stages, you are no longer deciding whether to buy. You are deciding whether what you bought survives being owned.