Seven Non-Obvious Lessons About Post-Merger Integrations

I’ve led three post-merger integrations ranging from $29M to $1.1B. Small ones we ran ourselves. The big one with consultants helping.

There’s a playbook to integrations. Every consultant has their own, each with a different take on the spreadsheets and templates you will need to track progress. But fundamentally, they all cover the same thing: synergy targets, new org structure, systems consolidation, Day 1 readiness, culture, communication, customer retention, the 100-day plan… it’s all in there. You have to stick to the playbook. You can’t skip pieces. Some will be easier for your business, some harder. Some more relevant, some less. But there’s a reason you do that stuff.

And yet, the playbook is a just about process. Consultants arrive and they leave—and they get paid regardless. As an operator, you have different skin in the game. You’re not just running workstreams; you’re accountable for the number, you’re managing the people, and you’re the one still there when the consultants pack up their laptops and go home.

Here’s what that taught me.

1. Get on top of the cross-functional programs early.

Integrations at the department level are obvious: every team will know the work it needs to do. It’s the cross-functional programs, though, that you need to stay on top of. These typically contribute the most to synergies, but they are not always easy to spot and the fact that they are cross functional makes them harder to do. By way of example, the goal of “consolidating CRMs” isn’t an IT/tech project—it’s a lead-to-order program. You can’t consolidate systems without aligning the GTM funnels and processes, which means Marketing, Sales, CS need to work with technology teams (perhaps both internal IT and client-facing engineers!).

If you’re accountable for the number, you need line of sight to every workstream that contributes to it. That often means creating horizontal programs that don’t exist in the standard playbook.

2. Tech mergers are harder than they look.

On paper, it is easy to justify the mothballing of one platform or system when the merger results in two systems doing essentially the same thing: you consolidate to save money.

The reality is often not as simple. The two companies will invariably have taken different approaches or have different functionality for legitimate reasons, and both are load-bearing: revenue runs through them. You can’t get rid of one without meaningful consequences.

The “logical” approach is to take the best of both. But that means you now must (re)build existing functionality into the go-forward system. That takes time and creates delay and perhaps frustration and uncertainty for clients. Or you can just tell the clients/users you’re removing functionality. That may lead to churn.

And these are just the objective issues. They don’t include the occasionally visceral connections engineers have with their work.

3. Cost synergies are controllable. Revenue synergies are not.

Cost is an action plan. You decide, you execute. Cut the role, exit the lease, cancel the contract. The savings show up when you say they will.

Revenue depends on customer behavior. Sales do not spontaneously materialize because you merged. Cross-selling each other’s products requires new motions that don’t yet exist. Nobody knows how to forecast it because there’s no baseline. The “synergy” is part-guess-part-hope dressed up as a projection.

Most deal models add cost and revenue synergies together like they’re equivalent. They are anything but.

4. Revenue misses become cost emergencies.

The deal model promised a revenue number. If the revenue synergies don’t show up on schedule, you still need to deliver a number. So you go back to the well—and, more often than not, the well is headcount.

The people who survived the first round get hit again. Now you’re cutting into muscle, not fat.

This is why you need real line of sight to revenue synergies early. Because when they don’t materialize, you can’t just forget about them, and your options run out quickly.

5. The Integration budget and the operating budget are not independent.

There are two aspects to this. The most important is simply that the company needs to keep on delivering even though the integration is happening. Even in companies that have a dedicated PMO or integration team, the integration and BAU will inevitably compete for the same resources. The integration plan needs your best people. The operating plan may assume they’re delivering the business.

The other is that tracking and allocating expenses can become tricky. There is often overlap, meaning costs or time that could be charged to either budget.

The bottom line is you need to think through how these two budgets interact. You can’t treat them as separate exercises.

6. Integration is not transformation.

It starts with: “While we’re in there, we should really fix this…”

And before you know it, the CRM consolidation becomes a CRM rebuild. The pricing harmonization becomes a pricing model redesign. The API migration becomes a platform re-architecture. Six months becomes 24. Customers are still waiting.

The goal of integration is to combine two things that work into one thing that works, not to build the thing you always wished you had. The discipline is knowing when to stop. Ship the ugly version. Harmonize now, optimize later.

7. The integration must end.

This isn’t like other deadlines. Miss a product launch and the org keeps going. Maybe someone gets fired, but life continues.

Integration is different. Your board and investors are waiting for the non-recurring items to stop. At some point they’re going to say enough is enough. The integration is the means to the end. The end is shareholder returns.

You don’t get to keep integrating indefinitely. The window closes, whether you’re ready or not. And if you’re not ready—especially if you’re a public company—the investment community will let you know.