Why 86% of M&A System Mergers Fail (And What Actually Works Instead)
Sync Room: Episode 4
Only 14% of M&A integrations achieve significant success, according to PwC. The other 86% don't fail because the deal was bad. They fail because two days after the press release, an engineer named Mike opens his laptop, sees three tools he didn't ask for, and starts copy-pasting tickets between systems for 35% of his week.
I'm Syed Majid Hassan, Head of Support and Services at Exalate.
In Episode 4 of Sync Room, my co-host Manoosh and I sat down with Mariia, our PMM and integration market expert, to break down why post-acquisition system integration goes sideways, and what teams running Jira, Jira Service Management, ServiceNow, Azure DevOps, Salesforce, Zendesk, or Freshservice should do differently from day one.
Here's what we learned in the field.
What is M&A integration in practice?
M&A integration is the process of aligning two companies' tech stacks, processes, and data flows after a merger or acquisition so that teams can keep doing their jobs without manual workarounds. It is not the same as a system migration. Migration moves data from one tool to another. Integration keeps both tools running and connects them through a sync layer.
The distinction matters because most leadership teams treat the tech stack as the third or fourth layer of the deal, after legal, HR, and logistics. By the time IT gets the brief, the merger has closed, the timelines are tight, and the engineers on the ground are already drowning.
Why do so many M&A integrations fail?
They fail because the merger gets treated top-down as a project, but the work happens bottom-up.
PwC's research shows the 14% success rate measures whether employees on both sides can continue doing their jobs confidently after the change. The other 86% land in a workplace where Mike, a database engineer, finds out on Monday morning that he now has to support a team in another system, duplicate tickets across two Jiras, and spend roughly 35-40% of his week on admin work by Friday.
That is not a strategy problem. It is an operations problem disguised as a strategy problem.
The customers don't care about your merger. They paid for a service, and they expect the same quality on Tuesday as they got on Friday. When productivity drops 35% in week one, that hits revenue before it hits any KPI dashboard.
What does it actually cost to run two disconnected systems?
It costs roughly $25,000 per engineer, per year, in copy-paste tax alone.
Here is the math we see in the field:
- 10 hours per week of manual ticket duplication between two ITSM tools
- $50/hour fully loaded engineering cost
- $500/week × 50 working weeks = $25,000/year per engineer
- Six acquisitions in two years = a six-figure copy-paste bill
A real example: a manufacturer we worked with acquired a downstream supplier. Different ITSM tools on each side. Quality engineers at the acquired plant spent close to two days a week duplicating work so the parent company had real-time visibility into the shop floor. Within six months, those engineers were demotivated, making mistakes in their actual jobs, mistyping defect codes, and letting supplier issues slip through the cracks. The customer never saw the merger. They just saw the slippage.
That is what we call corrosive work. It is not paid for, it is not measured, and it eats your best people first.
Why does the "just write a script" approach fail?
Because a script is a quick fix, not an integration strategy.
In the AI era, any decent engineering team can write a script that pushes data from System A to System B. The data starts moving. Leadership sees it implemented. Everyone goes back to their original jobs.
Then the API changes. The edge cases pile up. Someone needs an audit log. A field gets renamed. A new acquisition comes in with a fifth tool.
Three months in, the engineering team is maintaining a brittle pile of scripts instead of shipping product. Six months in, you have technical debt that nobody wants to own.
Building a sync engine is not your business. We covered this in detail in an earlier Sync Room episode on build vs. buy, but the short version: off-the-shelf solutions get to production in hours or days. DIY scripts take 3-5 months to reach production-ready quality, and then someone has to maintain them forever.
Why do consolidation and migration almost always backfire after an acquisition?
Because the tool is not the workflow. The tool is wrapped around the workflow. When you rip out an acquired company's Jira, ServiceNow, or Azure DevOps to consolidate into the parent's instance, you also rip out a decade of muscle memory, custom fields, automations, and operational plumbing.
The same manufacturer above eventually decided to consolidate everything into the parent's ITSM tool. Their acquired supplier had Jira tickets being created by barcode scanners on the shop floor. Automation rules assigned tickets to whoever was on shift. None of that survived the migration. Leadership budgeted six weeks of retraining. The actual cost was six months of operational losses.
Maria put it well: most migration tools cannot filter data in flight. They lift and shift, including the cruft. So you either inherit five years of unused custom fields you never wanted, or you spend months cleaning up afterwards. Either way, you are rescheduling work, not eliminating it.
And here is the pattern we see repeat: the multi-tool environment that was supposed to last two months during transition becomes the permanent reality. There is no clean migration. There is just a slower decline into copy-paste chaos.
What does a working M&A integration architecture look like?
It looks like this: each acquired company keeps its own tool, and a sync layer on top of each system controls what data crosses the boundary.
A service delivery company we worked with acquired six companies in two years and planned to acquire 21 more. They started with the consolidate-everything-into-one-system approach. By acquisition three, they realized they were running a full-time migration sweatshop instead of a business. They switched architectures.
Their final setup:
- Salesforce on the parent side, customer-facing
- A Jira instance from the acquired engineering company, untouched
- Two Freshdesk instances from other acquired support teams, untouched
- Exalate sitting on each system, syncing only the fields that needed to cross
No migrations. No consolidations. Each acquired team kept its workflows, its automations, and its muscle memory. The integration did the heavy lifting.
This is the same star network topology we see working for service desks supporting multiple vendors, and the same pattern that makes cross-border M&A actually viable.
How do you handle GDPR and cross-border M&A integration?
You keep the data on its own side. EU data stays in EU systems. US data stays in US systems. The integration layer filters what crosses the pond.
A US enterprise acquiring an EU startup runs into GDPR, data residency, and sector-specific rules in fintech, healthcare, and insurance. A "commingled" architecture, where both sides dump data into a central server, breaks one side legally, no matter where you put that server. If it sits in the US, your DPO has questions about EU data leaving the bloc. If it sits in the EU, US compliance gets uncomfortable.
The integration approach solves this structurally. If a Jira ticket on the EU side contains PII, the sync layer strips it before sending the operational data to the US side. The other side gets what it needs to do the work. The legal conversation finishes before it starts. We call that a compliance position: an architecture that automatically answers the questions legal would ask anyway.
What changes for the people on both sides when integration replaces forced merger?
The dynamic flips. Teams stop feeling like something is being done to them and start feeling like something is being built for them. That sounds soft until you look at the retention numbers: post-merger employee attrition spikes within six months when teams feel the integration was imposed. Replacing senior talent in a tight market is far more expensive than keeping it.
Ask Mike how his day works before you redesign his system. If you can't honor every request, fine, but the act of asking changes the dynamic. People who feel heard during a merger want it to succeed. People who don't, leave.
The other thing that changes: context survives. Migrations lose context. Sync preserves it. And in an AI-assisted workflow where context is the difference between a useful suggestion and noise, that compounds.
What's the ROI of M&A integration vs. the alternatives?
Three drivers, and the right baseline is the alternative cost, not zero.
Copy-paste tax avoided. $25K per engineer per year, per integration, scales fast across acquisitions.
Avoided migration cost. Migrations are multi-quarter projects with multi-team resource costs. Most CFOs underestimate the soft cost: people pulled off product work for six months.
Revenue protection. Customer-facing teams stay customer-facing. Retention and CSAT don't drop during the transition.
Compare that to the cost of a sync platform measured in active sync pairs, not seats or transactions, and the math is straightforward. The harder line item to defend is the do-nothing option, because the do-nothing cost is buried inside salary lines for engineers doing manual work that should not exist.
Key takeaways for Atlassian teams managing post-acquisition tool sprawl
If you're running Jira, Jira Service Management, or any Atlassian stack, and an acquisition is coming or has already happened:
- Don't migrate by default. Consolidation is the most expensive answer for the smallest number of cases. Sync first, evaluate later.
- Keep each acquired team in their tool. Their workflows, automations, and custom fields are five years of operational IP. Preserve them.
- Filter data at the integration layer. Field-level control is how you stay GDPR-compliant in cross-border deals.
- Pick your most exposed integration first. Ask which sync, if it broke, would hurt the most. Start there.
- Talk to the engineers actually doing the work. Mike knows where the chokepoints are. Leadership usually doesn't.
- Treat AI as a context multiplier, not a replacement. Integration done right preserves the context AI needs to actually help.
Summary
M&A system integration fails when leadership treats the tech stack as a checkbox and forces consolidation onto teams that need their existing tools to do their jobs. The 14% that succeed share one pattern: they integrate instead of merge, they preserve context instead of migrating it, and they design the architecture around the people doing the work.
Real-time bidirectional sync, with field-level control and independent configuration on each side, is the only approach that scales across multiple acquisitions, cross-border compliance, and the messy reality of post-deal operations.
If you're staring at a post-acquisition tool sprawl right now, start with the most exposed connection. Map what data has to cross. Filter the rest. The mountain gets smaller from there.
Join us for Episode 5
The next Sync Room episode dives into MSP integration patterns and what happens when you're the integration layer between your customer's tools and your own. If you've got an M&A integration story, an exotic cross-border use case, or a question about Jira-to-anything sync, drop it in the comments or reach out directly. Happy to dig in.
You can also watch the full Episode 4 recording on the Sync Room hub or try the New Exalate experience on the Atlassian Marketplace.