What Actually Breaks During Integrations (And Why)
Integration Insights, Part 1 of 3
I have worked on integrations across public companies, private companies, and PE-backed portfolios. The deal types differ. The industries differ. The org charts differ.
The failure patterns don’t.
Study after study puts the failure rate of mergers and acquisitions between 70% and 90% (Christensen et al., “The New M&A Playbook,” HBR, March 2011). That number gets cited constantly. What gets discussed less often is the specific, preventable reasons why integrations break. Not the high-level ones. The operational ones. The ones I’ve watched happen, in real time, across multiple clients.
This is a three-part series. Part 1 is what actually breaks. Part 2 is what separates fast integrations from slow ones. Part 3 is what PE sponsors consistently get wrong, and what works instead.
Let’s start with the breaks.
The timeline was wrong before the work started.
Every integration I have seen begins with a target date. That date is almost always set before anyone has mapped the real dependencies.
I’ve watched teams commit to go-live timelines while core system decisions were still unresolved. Months into the work, with the calendar closing in, the team finally collides with the constraint that was always there. The timeline doesn’t slip. It collapses. And the people doing the work, who saw it coming, lose credibility for having stayed quiet.
The fix isn’t a better Gantt chart. It’s honest dependency mapping before the date gets announced. Ask: what has to be true before the next thing can move? Work backwards. Only then set the date.
External bodies are on nobody’s critical path.
This is the one that catches leadership off guard most reliably.
Integrations involving regulated industries require approvals from external bodies. Accreditors. State licensing boards. Federal agencies. State agencies. These are not administrative formalities. They are actual gates. And unlike internal milestones, you cannot manage them. You can only prepare for them and wait.
I’ve worked on integrations where federal agency capacity was materially reduced mid-process due to external factors entirely outside the company’s control. I’ve watched state licensing requirements invalidate an entity structure that had already been implemented. The common thread: these dependencies were known. They weren’t scheduled as constraints.
When an external body controls a critical path, the integration plan needs to show that clearly. Not buried in a risk log. On the front page.
IT decisions got made without the business in the room.
This one is expensive. Literally.
The pattern looks like this: IT selects a vendor, runs a process, signs a contract. The business finds out when the system is being implemented. The business rejects the functionality. Now you have a contract, a vendor, and a team that has to rebuild from scratch.
I’ve seen this lead to seven-figure rework. I’ve seen it delay integrations by a year. The root cause is almost always the same. Technology selection happened as a technology decision, not a business decision. Requirements weren’t written by the people who would live in the system. Business leaders weren’t in the evaluation.
The test is simple: before any vendor is selected for a system that touches operations, the operational owner has to sign off on the requirements first. Not after. Requirements first, vendor second. Reverse that sequence and you will pay for it.
“Best of both worlds” is not an integration philosophy.
Every integration has a stated culture philosophy. It usually sounds like: “We’re not acquiring them, we’re combining the best of both organizations.”
What actually happens is one of two things. Either the acquirer’s operating model quietly becomes the default and the acquired entity feels absorbed regardless of the language. Or both entities protect their existing ways of working and the integration never really happens.
I’ve seen leadership announce a philosophy of mutual respect and collaboration, while simultaneously signaling to their own teams that their operations were not going to be disrupted. The acquired organization felt the contradiction immediately. The anxiety it created slowed the work for months.
For most integrations, culture alignment is a decision problem masquerading as a communications problem. At some point, someone has to decide how the combined entity will actually operate. That decision has to come from leadership, explicitly, and it has to hold. Platitudes don’t do it.
Integration work is piled on top of day jobs.
This last one is predictable. It still breaks things every time.
The people best positioned to do integration work are the ones who understand operations most deeply. Those people already have jobs. When integration work lands on top of their regular responsibilities, one of two things happens: the integration work gets deprioritized, or the day job suffers. Usually both, in rotation.
Math is math. You can’t motivate your way out of a capacity problem. Integrations move faster when someone owns them as their primary responsibility, not as a side project. When that’s not possible, the scope has to match the bandwidth. Integration teams that are stretched too thin make decisions too slowly, miss dependencies, and produce work that has to be redone.
The question to ask at the outset: who is actually accountable for this, and what are they being asked to stop doing so they can do it?
These five patterns aren’t exotic. They aren’t new. They show up across industries, deal sizes, and ownership structures because they are fundamentally human problems. Timeline pressure creates wishful thinking. Regulated dependencies are uncomfortable to plan around. Internal politics make honest conversations about culture difficult. And everyone’s already busy.
Knowing the patterns doesn’t make the integration easy. But walking in without knowing them guarantees you’ll be surprised.
Part 2 covers what separates integrations that move fast from those that stall. Subscribe to EDSO Edge so you don’t miss it.
Ready to assess your integration readiness before the friction starts? Schedule a discovery conversation.
About Amelia Waters
Amelia Waters is the Managing Partner of EDSO Edge, a strategic growth and operations consulting firm serving PE-backed healthcare education and EdTech companies. Her background spans BCG, a decade at Kaplan, and COO roles at PE-backed companies. She writes Ideas from the Edge for executives and high-performers on systems thinking, leadership, and the operating principles she finds in everyday life.
Learn more at edso-edge.com.