The Seven Deadly Claims 3/7:  "Fully Integrated." Acquired Assets.

Buy vs.build is one of the most common software strategies in mid-market PE. Buy a platform, add products around it, sell the suite into the base, and take cost out of the combined platform. So EVERY CIM for a bought asset makes the same claim about the add-ons: fully integrated.

I've learned to ask what that means at the level of code, data and team, because "fully integrated" isn't a level of integration. It's a phrase that covers everything from a shared logo to a shared codebase.


Here's the ladder I use:

  1. Commercial. One contract, one invoice, one sales team. Creates bundling and pricing leverage.

  2. Cosmetic. Common login, common navigation, common visual design. Creates a suite experience in the demo.

  3. Data exchange. Specific, defined integration points that pass data between products to support specific workflows.

  4. Shared data model. Common core objects and one source of truth. This is what makes cross-sell possible without an implementation project, and what lets AI work across the suite.

  5. Shared platform. One codebase, one infrastructure, one release train, one team. This is where the R&D and hosting savings in the synergy case actually come from.

In my experience, most acquisitions described as fully integrated are at level two. The acquired product got a new header and a single sign-on. Underneath, it still runs on its own stack, its own database, its own release cycle, and often its own engineering team that was never merged.

Cosmetic integration isn't worthless. It supports a suite story and a single contract. But the investment case for an acquisition almost always rests on cross-sell, shared workflows and platform savings, and none of those come from a superficial integration.

The questions that get past the phrase are specific. List every integration point: what data moves, which direction, how often, and what workflow does it enable? How many customers use both products, and how many bought the second one after the acquisition closed? What's the attach rate into the base, and how long does a cross-sell implementation take? Is the acquired product on the same infrastructure, release cycle and team? If not, when, and is it funded?

My favorite question is the simplest. What did the integration plan at close promise, and what's been delivered against it? Most companies can find the plan. Fewer can show the status.

For deal teams, ask for the original integration plan with status by item, a customer-level cross-sell view, the architecture diagrams showing where the acquired product really runs, and R&D and hosting cost for the acquired product before and after close.

For portfolio companies with an exit on the horizon, be honest about where each acquisition sits on the ladder, and then pick the one or two integration points that create real cross-sell value and build those properly. A buyer will credit two real cross-product workflows with attach data behind them. They will discount a slide that says "fully integrated."

The red flag: the integration is cosmetic, attach is low, and the acquired product still has its own stack and team two years after close. At that point, the platform is a holding company for separate products, and the synergy case is still ahead of you, not behind you.

Next week: the migration that never ends.

Next
Next

The Seven Deadly Claims 2/7:  "We Integrate With Hundreds of Systems."