Seven Non-Obvious Lessons About Post-Merger Integrations

I’ve led three post-merger integrations ranging from $29M to $1.1B. The small ones we ran ourselves. The big one we hired consultants as well.

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. 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 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 or you’re managing the people. Ultimately, 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 the obvious place to start. Every team will need to figure out the new org chart and how to integrate the work it needs to do. It’s the cross-functional programs, though, that often make or break synergy achievement. The challenge is that these are often unique to the company and require creating horizontal programs that don’t exist in the standard playbook. 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 which consist usually of internal IT and client-facing engineers.

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 neither can be summarily axed because they support revenue.

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. Then there are the preferences engineers have (and occasionally visceral connections) with certain ways of doing things.

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

Cost is an action plan. You decide, then you execute: reduce headcount, 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 and assumes clients will buy what they hadn’t previously. 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. There is only one place from which that number gets delivered: cost reductions. More often than not, the easiest place to find savings is headcount, which means that the people who might feel lucky to have survived the first round of cuts are subject to a second. 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 run out of options 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.

The path to integration hell is paved with good intentions. 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.

Integrations are not like other projects. If you miss a product launch, 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.