← All insights

Acquisition integrations · Program leadership

An acquisition integration is a business transformation wearing an IT costume.

Most companies fund an acquisition integration like a data migration and run it like an IT project. Then they lose the people. After more than 15 of these, here's what the costume hides.

By David ApollonJune 30, 20269 min read

The deal closes. Legal is done, the press release is out, and someone hands IT a date: get the acquired company onto our systems by year end. On paper it looks like a data migration. Move their people and their numbers into our tenant, flip the switch, done.

That framing is how acquisition integrations go wrong. I've run more than 15 of them, and the technology is rarely what sinks one. What sinks it is treating a business transformation like an IT project.

The acquired employees are losing the systems they know, the processes they built, and in a lot of cases the autonomy they had before the deal. Manage that as a data load and the data will land fine while adoption falls apart underneath it.

The plan IT gets handed, and what sits under each line

On the planGet the acquired company onto our systems by year end.
Underneath
  1. Data migration, underneath: A business transformation
  2. Licenses, an SI statement of work, a cutover weekend, underneath: The human system nobody put on the Gantt chart
  3. A database, underneath: A company full of people deciding whether to stick around
  4. Deployment, a date, underneath: Adoption, a behavior
  5. Configuration and testing, underneath: Power users from the acquired side, skeptics first
  6. Data mapping, underneath: Whose business logic wins
  7. Command center, underneath: Buying trust

Integration budget: licenses, SI statement of work, cutover weekend

Why it gets funded as IT

An integration has a budget line, and the people who own it think in systems. Everything on that line is real. It's also only the part you can see.

The data backs up how often the technical side goes wrong.

47%
of failed deals have IT problems behind themIndustry analyses, approximate
80%
of value-losing deals went into signing with no real technology integration planIndustry analyses, approximate
83%
of deals underperform the case that justified themKPMG
42%
of due diligence never produced a workable synergy roadmapMcKinsey

Read those a second time. Every one of them is a symptom, and each has a cause sitting under it.

A missing integration plan
is a planning failure
A botched cutover
is a governance failure

The technology gets blamed because it's the thing that visibly breaks. The cause sits upstream, in the human system nobody put on the Gantt chart.

Stand up a flawless tenant

You lose the people

The attrition numbers should reframe the whole effort. MIT Sloan research puts first-year attrition among acquired-company employees at 34%, against 12% for people hired the normal way. EY finds 47% of key employees gone within a year, and 75% within three.

Share of people gone after an acquisition
  • Acquired-company employees, first year34%
  • Key employees, first year47%
  • Key employees, within three years75%
  • People hired the normal way, first year12%

MIT Sloan (34% and 12%); EY (47% and 75%).

You can stand up a flawless tenant and still watch a third of the acquired workforce walk out, taking the institutional knowledge you just paid a premium for with them. The deal model assumed they'd stay. The integration is what decides whether they do.

You bought a company full of people who are now deciding whether to stick around. The integration is the first thing they judge you on.

Status: green

Green on the outside

My rule on these programs: a green status that nobody on the acquired side believes has already stopped being green.

I've watched a cutover reported as a success while the acquired finance team kept their old spreadsheet running on the side, because they didn't trust the new system and nobody had earned that trust.

Deployment is a date.

Adoption is a behavior.

The gap between the two is where the deal case goes to die.

Configuration and testing

Recruit the skeptics early

From the start, I pull power users from the acquired company into configuration and testing, and I go after the skeptics first.

They're the only people who understand their own edge cases: the reason a process has a weird extra step, or the customer who gets invoiced differently for a reason that predates everyone in the room. Bring them in early and two things happen. The design comes out right, and they walk back to their teams as the people who shaped the new system.

A technically flawless deployment still fails if the users reject it. Power users are how you stop the rejection before it starts.

Data mapping: cost centers, job profiles, financial dimensions

Data is a people problem wearing a spreadsheet

Acquired companies don't categorize data the way you do. Their cost centers, job profiles and financial dimensions encode years of their own decisions, so mapping them to yours turns into a negotiation about whose business logic wins.

I run a workstream dedicated to data translation, and I treat clean, validated data as the entry ticket to testing. It gets fixed before a test cycle starts.

When the mapping turns into an argument, the integration is finally surfacing a decision the deal model never made.

IT war room

The command center is change management with a clock

Go-live takes minute-by-minute sequencing: extraction, lockdown, load, validation. A well-resourced command center triages the issues that always come. It stays active through the most critical early milestone, the first combined month-end close, and stands down only when stability and adoption are firmly met.

Go-live, then the command center
  1. Extraction
  2. Lockdown
  3. Load
  4. Validation
  5. Command center active through the first combined month-end close
  6. Stands down when stability and adoption are met

From the outside it looks like an IT war room. What it's doing is buying trust. Every issue resolved fast in week one is a deposit in the account that decides whether the acquired team adopts the system or revolts against it.

Tenant go-live

Strip the costume off

An acquisition integration is a business transformation that happens to run on systems. Fund the systems, absolutely. Then staff the human side like the deal depends on it, because it does. The tenant will go live either way. Whether the people come with it is the part you paid for.

I've run this play across more than 15 acquisitions: Workday to Workday, legacy ERP to Workday, and platform migrations on their own. The full approach is here: how I run an acquisition integration. If you have one coming, book a call or find me on LinkedIn.

Sources: McKinsey, Where mergers go wrong and synergy research; KPMG synergy-realization survey; MIT Sloan and EY research on post-acquisition attrition. The figures are industry benchmarks that frame the pattern. They don't model any one deal.

Integrating an acquisition?

Put independent eyes on it before Day 1.

Workday to Workday, a legacy system folded into your ERP, or a platform migration on its own, the program discipline is the same. Bring me in early and the people come with the system.