An Acquisition Integration Is a Business Transformation Wearing an IT Costume.

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 have run more than 15 of these. The technology is rarely what sinks them. What sinks them is treating a business transformation like an IT project. The acquired employees experience something other than a software upgrade. They 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 be fine while the adoption quietly collapses.

1 Why it gets funded as IT

An integration has a budget line, and that budget line has owners who think in systems. Licenses, an SI statement of work, a cutover weekend. All of it is real, and all of it is the part you can see.

The data backs up how often it goes wrong on the technical side. Industry analyses put IT problems behind roughly 47% of failed deals, and find that around 80% of value-losing deals went into signing with no real technology integration plan. KPMG's synergy work shows 83% of deals underperforming the case that justified them.

Read those a second time. They describe symptoms, not the disease. A missing integration plan is a planning failure. A botched cutover is a governance failure. The technology gets blamed because it is the thing that visibly breaks. The cause sits upstream, in the human system nobody put on the Gantt chart.

2 You don't lose the deal. You lose the people.

Here is the number that 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.

Those are not IT numbers. You can stand up a flawless tenant and still watch a third of the acquired workforce walk, taking the institutional knowledge you just paid a premium for out the door with them. The synergy model assumed they would stay. The integration is what makes them stay or leave.

You did not buy a database. 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.

3 Green on the outside

My rule on these programs is simple. A green status that nobody on the acquired side believes has already stopped being green.

I have watched a cutover reported as a success while the acquired finance team quietly kept their old spreadsheet running on the side, because they did not 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 synergy case goes to die.

4 Recruit the skeptics early

The single highest-leverage move I make is pulling power users from the acquired company into configuration and testing from the start. Not as a courtesy. As strategy.

They are the only people who understand their own edge cases. The reason a process has a weird extra step. 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 gets right, and they walk back to their teams as the people who shaped the new system, not the people it was done to.

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

5 Data is a people problem wearing a spreadsheet

Acquired companies do not categorize data the way you do. Their cost centers, job profiles, and financial dimensions encode years of their own decisions. Mapping them to yours goes well beyond a technical exercise. It is a negotiation about whose business logic wins.

So I run a workstream dedicated to data translation, and I treat clean, validated data as the entry ticket to testing, not something we fix during it. When the mapping turns into an argument, you are past a scheduling problem. That is the integration finally surfacing a decision the deal model never made.

6 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.

The command center looks like an IT war room. What it is 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.

An acquisition integration is a business transformation wearing a systems costume

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 have 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. Figures are industry benchmarks, included to frame the pattern, not to model any one deal.