{"id":65,"date":"2026-07-10T15:14:05","date_gmt":"2026-07-10T15:14:05","guid":{"rendered":"https:\/\/datadrivenops.co\/blog\/?p=65"},"modified":"2026-06-09T14:07:52","modified_gmt":"2026-06-09T14:07:52","slug":"ma-integration-best-practices-lessons-learned","status":"publish","type":"post","link":"https:\/\/datadrivenops.co\/blog\/ma-integration-best-practices-lessons-learned\/","title":{"rendered":"M&A Integration Best Practices:Lessons Learned\u00a0from Real Projects"},"content":{"rendered":"

I’ve run M&A integration from the inside — leading both the Customer Support and Corporate IT workstreams of a 254-person merger with a 30-day target for operational alignment. There are frameworks and playbooks for this kind of work. Most of them are right in the abstract and insufficient in practice. You can read the full operational story in the AudienceView\/Vendini case study<\/a>, and a detailed breakdown of the 30-day timeline in Running the Ops Workstream in an M&A Integration<\/a>. What follows are the specific lessons — the decision that had the biggest downstream impact, the crisis that nearly derailed it, the thing nobody tells you about acquiring companies, and the outcomes that only became possible because of the work done in the first week.<\/p>\n

The Decision That Mattered Most: Learn Before You Lead<\/h2>\n

The single most valuable thing I did in the first 48 hours wasn’t issuing an org chart or aligning on tooling. It was sitting down with the teams on the acquired side and asking questions. What do you do, exactly? How do you do it? What tools do you use? Who are your customers, and what do they actually care about? Where are your peaks and valleys in demand, and how do you staff to them?<\/p>\n

This sounds obvious. Most integration leaders skip it, or compress it into a brief due diligence review conducted by people who weren’t going to run the operation. Heidrick & Struggles’ research on M&A leadership talent<\/a> consistently identifies this gap as a primary driver of integration failure: organisations apply rigorous due diligence to financials but far less to understanding how work actually gets done. The result is an integration designed around assumptions rather than reality.<\/p>\n

What that learning revealed in our case was significant. The acquired company had a culture of throwing developer resources at software bugs as they appeared — a reactive approach that kept the bug count perpetually high and support volume consistently elevated. Once we understood the pattern, the solution was clear: redirect developer effort toward fixing underlying issues systematically rather than patching symptoms. Within the first six months post-acquisition, the open bug count dropped by 60–80%. That reduction drove a roughly 40% decrease in inbound call and ticket volume — which fundamentally changed the resource requirements of the combined support operation.<\/p>\n

\n
60–80%<\/span>Open bug count reduction<\/span><\/div>\n
~40%<\/span>Inbound volume reduction<\/span><\/div>\n
6 months<\/span>To achieve both outcomes<\/span><\/div>\n<\/p><\/div>\n

The Crisis: Brain Drain<\/h2>\n

The hardest moment in the integration wasn’t the systems migration or the org design. It was the brain drain that followed close. This is far from unusual — research from ClearlyAcquired<\/a> puts the figure at nearly 50% of key employees leaving within the first year post-close, with that number climbing to 75% within three years. Replacing a single key employee can cost between 50% and 200% of their annual salary — and that’s before accounting for the institutional knowledge they take with them.<\/p>\n

In our integration, key people left. The ones who left often took exactly the institutional knowledge the integration most needed: processes that had never been documented, customer context accumulated over years, tribal understanding of why the product worked the way it did. The kind of knowledge that a well-run support operation captures systematically in its knowledge base and incident management processes<\/a> — but that fragmented, reactive operations leave in people’s heads.<\/p>\n

We responded on two fronts. Retention bonuses bought time. McKinsey’s research on M&A talent retention<\/a> makes a point we learned firsthand: financial incentives stabilise the immediate situation, but what keeps people is clarity about their future in the combined organisation, communicated early and often. The real fix was aggressive documentation — end-to-end customer journeys, pain point mapping, process documentation that captured how work actually got done. We built this under pressure, which meant it was imperfect. But imperfect documentation is infinitely more valuable than none. The knowledge base and training infrastructure we’d already built at AudienceView<\/a> gave us a framework to capture this material quickly — one more reason to build those systems before you need them urgently.<\/p>\n

\n

By the time the brain drain is visible, you’ve already lost the people who had the most to contribute to the documentation. Start capturing institutional knowledge from day one.<\/p>\n<\/blockquote>\n

The Systems Migration: Losing a Tool Your Team Loves<\/h2>\n

One of the more delicate integration decisions was the ticketing platform. The acquired company ran on Zendesk — an excellent system with an integrated customer-facing knowledge base, strong reporting, and an interface the team had invested years optimising. Our platform was more bare-bones. The team on the Zendesk side knew it.<\/p>\n

The decision to migrate wasn’t primarily about cost — it was about operating from a single system rather than maintaining two separate support stacks. But we went in clear-eyed about what was being asked. The agent experience with their tools directly affects the experience they deliver to customers — a point CXMaster makes compellingly in the context of CX investment and returns<\/a>: the link between internal tooling quality and external customer outcomes is direct, and dismissing it creates problems that show up in your CSAT scores months later.<\/p>\n

Two things made the migration work. First, we protected what mattered most: every knowledge base article was migrated and preserved, customer history came across, and no customer-facing content was lost. Second, the migration was gradual, supported by genuine cross-training — not a weekend cutover. The team had time to build familiarity before they were dependent on the new system. When you’re asking a team to give up a tool they love, the transaction has to feel fair.<\/p>\n

The First 48 Hours: What Most Ops Leaders Skip<\/h2>\n

These three things complement the tactical 30-day timeline I’ve covered in the ops workstream post<\/a>. They’re the mindset decisions that make the tactical ones land properly.<\/p>\n

\n
\n
01<\/div>\n
\n
Meet the people before you touch the processes<\/div>\n
Not a brief introduction — actual working sessions with the teams on both sides. Understand what they do, how they do it, and what they think is broken. The integration decisions made on the basis of this knowledge are categorically better than ones made without it. This is how you find the bug backlog problem before you’ve committed to a support model that doesn’t account for it.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n
02<\/div>\n
\n
Issue a provisional org structure within 48 hours, explicitly framed as provisional<\/div>\n
Ambiguity about reporting lines costs more in anxiety and lost productivity than almost anything else in the first two weeks. A temporary structure everyone knows is temporary is better than none. People can tolerate a lot of uncertainty about the future if they know who they’re working for today.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n
03<\/div>\n
\n
Start the documentation immediately, before anyone leaves<\/div>\n
Identify the people in both organisations who are the primary holders of institutional knowledge — the ones who know how things actually work, not just how they’re documented. Get sessions on the calendar with them in the first week. The documentation you capture in week one is worth ten times what you can reconstruct three months later.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n

The SLA Question Nobody Asks Soon Enough<\/h2>\n

One thing that gets lost in the operational chaos of integration is the service level question: what commitments is each team currently making to customers, and how do those commitments interact in the combined entity? Mergers frequently surface a mismatch between the SLAs each organisation has promised externally and the internal commitments — or lack thereof — that underpin them.<\/p>\n

The OLA framework we’d built at AudienceView<\/a> before the Vendini merger made the integration cleaner. We already had defined internal response commitments across hosting, engineering, and support. The Vendini team could be onboarded to a structured framework rather than an informal set of expectations. As the team at CXMaster has written about internal vs. external SLAs<\/a>: your internal commitments have to outpace your customer-facing ones, or the customer-facing ones are aspirational rather than achievable. Get the internal framework defined before the merger closes if at all possible.<\/p>\n

The Lesson Nobody Tells You<\/h2>\n

The acquiring company assumes its people are safe. That’s the implicit logic: we bought them, so we’re the ones with job security. That’s wrong, and acting on it is one of the most expensive mistakes an integration leader can make.<\/p>\n

In any merger, both organisations have exceptional people. Both also have people who aren’t the right fit for the combined entity — including people from the acquiring side. The person who was the best fit for the old structure may not be the best fit for the new one. The integration is the moment to design the organisation you actually want, not to preserve the acquiring company’s hierarchy with an acquired company grafted onto it. McKinsey’s research on M&A talent strategy<\/a> makes the same point: organisations that get this right engage leaders from both sides in defining the end-state structure, rather than defaulting to the acquiring company’s existing hierarchy.<\/p>\n

\n

The integration is the moment to design the organisation you actually want. Not to preserve the acquiring company’s hierarchy with an acquired company grafted onto it.<\/p>\n<\/blockquote>\n

The Metrics That Tell You the Integration Is Working<\/h2>\n

Customer-facing metrics.<\/strong> CSAT, ticket volume, and resolution times should stabilise and then improve in the first six months. PwC’s research on customer experience in M&A<\/a> shows that customers notice integration disruption quickly and that CX metrics are often the earliest honest signal of whether an integration is going well. Understanding how to connect CX performance to financial outcomes<\/a> is what gets leadership to take early warning signals seriously.<\/p>\n

Staff retention.<\/strong> Track it explicitly, by team and by seniority level. The people most likely to leave are often the most valuable to retain. If retention is deteriorating in a particular area, something in that team’s integration experience is wrong — find out what before it’s too late to fix.<\/p>\n

KPI improvement against the underlying problems.<\/strong> In our case, the bug count and inbound volume. The integration wasn’t just about combining two organisations — it was about building something better than either had been separately. If the KPIs aren’t improving in areas where the integration should be creating value, the answer usually leads back to something learned, or not learned, in the first week.<\/p>\n

\n

Related reading<\/h4>\n