You Didn’t Integrate. You Just Delayed the Problem.
The second in a series talking about where PE rollups actually win or lose - in the systems.
Most rollups say they’ve “integrated” an acquisition. What they usually mean is:
Users can log into the same systems
Some data is visible across teams
Reports can be stitched together (with effort)
On the surface, it looks unified. Underneath, it’s still fragmented.
This is the most common failure point I see in rollups: Confusing access with integration.
What Passes for Integration (But Isn’t)
After an acquisition, there’s pressure to move quickly, so teams do what’s easiest:
Stand up SSO
Connect systems with lightweight integrations
Map a few key fields
Build reporting layers to “normalize” the data
It creates the appearance of alignment. But none of the underlying problems are actually solved. You still have:
Different data definitions
Different process flows
Different ownership models
Different assumptions about how the business runs
So instead of one company, you now have multiple operating models sharing the same tools.
The Hidden Cost of “Light Integration”
This approach works just well enough to pass early, which is exactly why it’s dangerous. Over time:
Exceptions start piling up
Teams adapt locally
Workarounds become standard practice
Reporting requires more manual intervention
And eventually, the system reflects everything… and explains nothing. At that point, every decision takes longer:
Finance doesn’t trust the numbers
Sales operates on different definitions
Leadership debates which report is “right”
Not because the data isn’t there. Because it was never designed to be consistent.
Why This Happens
Because true integration is harder than connecting systems. It requires decisions that feel slower upfront:
What is the single definition of revenue?
What is the standard order-to-cash process?
Which system is the system of record for each function?
Who owns the data when something breaks?
These aren’t technical questions, they’re operating model decisions. And if they aren’t made early…They get made implicitly, over time, by whoever is closest to the problem.
What Real Integration Actually Looks Like
Real integration is not about connecting systems. It’s about collapsing multiple ways of operating into one. That means:
One data model
One set of definitions
One clear ownership structure
One primary way of executing core processes
This doesn’t mean everything is identical. But it does mean everything is intentional.
The Tradeoff Most Teams Avoid
Real integration feels slower at the start because you’re forcing alignment instead of deferring it. But here’s the reality:
You will pay the cost either way.
Upfront, through disciplined integration
Or later, through compounding complexity
One is visible. The other shows up as drag across the entire business.
The Bottom Line
If your integration strategy is: “Connect it now, clean it up later,” you didn’t solve the problem.
You scheduled it.
And by the time you come back to fix it…You’re no longer integrating one company.
You’re untangling many.
In the next article, I’ll break down the three integration models every rollup falls into and why most teams end up choosing one by accident.