The Acquisition Nobody Planned For

A century-old industrial manufacturer acquires a European competitor. The deal makes strategic sense — complementary product lines, new markets, cost synergies that look brilliant on a PowerPoint slide. The business case is solid. The board approves it. The press release goes out. Everyone celebrates.

Six months later, the CTO is staring at two completely different cloud estates, two different CI/CD pipelines, two different identity systems, two different monitoring stacks, two different on-call rotations, and a bill for platform consolidation that nobody included in the acquisition model.

I’ve seen this pattern three times in the last five years. It never gets easier. And the engineers who have to deal with it are always the last to find out.

The due diligence gap

When a large company acquires another large company, the due diligence process is exhaustive — for finance, legal, HR, and intellectual property. Teams of consultants spend months going through every contract, every liability, every regulatory obligation. Nothing is left to chance. Except technology.

Technology due diligence, when it happens at all, is a surface-level exercise. “What cloud are you on?” “AWS.” “Great, us too.” Or worse: “Azure.” And then a long silence.

The questions nobody asks during due diligence:

• How many AWS accounts do you have? (The answer is always more than they think.)
• What’s your IAM model? Federated identity? Service accounts? Shared credentials? (Someone just winced.)
• How do you deploy? Jenkins? GitHub Actions? Azure DevOps? A shell script that Dave wrote in 2019? (It’s always Dave.)
• What’s your monitoring stack? Do you have SLOs? Do you have on-call? Who gets paged?
• How much technical debt are you carrying? Not “a bit” — quantify it.
• What’s your data residency situation? GDPR? Industry-specific regulations?

These aren’t nice-to-have questions. They’re the difference between a $2M integration project and a $20M one. And yet they routinely get skipped because the people doing due diligence don’t know to ask them, and the people who would know the answers aren’t in the room.

I worked on one acquisition where the acquirer discovered — after the deal closed — that the acquired company was running a significant portion of their workloads on a managed Kubernetes platform that the acquirer’s operations team had never seen before. The acquirer’s entire infrastructure was built on a different cloud provider’s container service. The two systems shared nothing: not the container runtime configuration, not the networking model, not the monitoring, not the deployment pipelines. Not even the same cloud.

The CFO had budgeted six months and a small team for “IT integration.” The actual cost was eighteen months, a dedicated programme of fifteen engineers, and a number with enough zeros to make the finance team quietly revisit their acquisition model.

The five phases of post-merger tech consolidation

After watching several of these play out, I’ve noticed the same phases every time. They’re as predictable as the Gartner Hype Cycle, and about as useful to know in advance — you still have to live through them.

Phase 1: “Let them run independently” (planned: 3 months, actual: 18 months)

This is the sensible starting position. Don’t touch anything. Let the acquired company keep running their stack while we figure out the integration plan. Minimise disruption. Focus on the business integration first.

The problem is that “let them run independently” is comfortable. Nobody wants to start the hard work of consolidation because it’s painful, risky, and politically charged. So “3 months while we plan” becomes 6 months, then 12, then 18. Meanwhile you’re paying for two of everything: two cloud bills, two monitoring platforms, two sets of on-call rotations, two security teams reviewing two different architectures.

I’ve seen organisations still running “independent” platforms three years after an acquisition. At that point it’s not a transition plan, it’s the permanent architecture. And it’s costing a fortune.

Phase 2: “We’ll standardise on our stack” (the announcement that alienates everyone)

Eventually, someone in leadership decides that the acquired company needs to migrate to the acquirer’s platform. This is usually announced in an all-hands meeting with phrases like “unified engineering culture” and “platform synergies” and “one team, one toolchain.”

What the acquired team hears: “Everything you built is rubbish and we’re replacing it.”

This is where things get toxic. The acquired engineers chose their tools for reasons. They built their platform over years. They know its strengths and weaknesses intimately. Being told to abandon it — often by people who’ve never seen it — is demoralising. The best engineers leave. The ones who stay are resentful. The “unified culture” the leadership wanted becomes “us vs them.”

The worst version of this is when the acquirer’s platform is genuinely worse than the acquired company’s, but standardisation happens anyway because the acquirer is bigger. I’ve watched an acquired team with a sophisticated GitOps deployment pipeline get forced onto a Jenkins server that was held together with cable ties and prayer. The justification was “standardisation.” The result was a step backward in every measurable dimension.

Phase 3: The identity crisis (literally)

Two organisations means two identity systems. The acquirer uses Azure AD (sorry, “Microsoft Entra ID” — the rebrand nobody asked for). The acquired company uses AWS IAM Identity Center with Okta federation. Or maybe both use Azure AD but with different tenants, different conditional access policies, different MFA configurations, and different group structures that encode years of organisational history that nobody documented.

Identity consolidation is the hardest part of any merger integration, and it’s always underestimated. It touches everything: cloud access, application authentication, VPN, email, file shares, SaaS subscriptions, API keys, service accounts, secrets management. You can’t migrate workloads until you’ve sorted identity, and sorting identity requires understanding both organisations’ access models — which are never documented accurately.

The fun part is when you discover that the acquired company has service accounts with hardcoded credentials in production configurations that nobody knows about. That’s always a good afternoon.

Phase 4: The data migration nobody budgeted for

Data is where acquisition integrations go to die. The acquired company has petabytes of data in a data lake on one cloud. The acquirer’s analytics team is on another cloud. The data needs to move — or be accessible from both places — and nobody factored in the egress costs, the schema differences, the data quality issues, or the regulatory constraints.

Cloud egress charges are the industry’s favourite hidden cost. Moving a petabyte of data out of AWS costs roughly $90,000 at standard rates. Moving it into another cloud is free (funny how that works). And that’s just the transfer cost — the actual migration work (schema mapping, data validation, ETL pipeline rebuilding) takes months.

I’ve seen data migrations that were estimated at six weeks take over a year. The schema differences alone can be devastating. One system stores dates as UTC timestamps. The other stores them as local time with no timezone indicator. One uses customer IDs as integers. The other uses GUIDs. One has a “status” field with four possible values. The other has fourteen, three of which mean the same thing.

Nobody includes this in the acquisition business case. Ever.

Phase 5: Acceptance (the dual-cloud reality)

Eventually, most organisations arrive at an uncomfortable truth: full consolidation isn’t going to happen. At least not on the timeline or budget anyone imagined. The pragmatic approach is to accept a dual-cloud (or multi-cloud) reality and manage it deliberately rather than pretending it’s temporary.

This means investing in cross-cloud networking, unified observability, consistent security policies, and — most importantly — a team that understands both platforms. Not “Azure experts” and “AWS experts” who never talk to each other, but engineers who can operate across the boundary.

This is actually fine. Multi-cloud is a reality for most large enterprises, whether they planned it or not. The problem isn’t having two clouds — it’s pretending you don’t, or refusing to invest in managing the complexity that comes with it.

What I wish leadership understood

The engineers who do this work — the migration engineers, the platform consolidation teams, the identity specialists — are doing some of the hardest, most thankless work in enterprise technology. They’re reverse-engineering undocumented systems, migrating production workloads with zero downtime, and managing the political fallout of telling two teams that one of them has to change everything.

This isn’t “keeping the lights on” work. It’s complex engineering that requires deep knowledge of both platforms, strong communication skills, and the patience of a saint. And yet it’s routinely treated as a cost centre, staffed with contractors (hello), and given unrealistic deadlines by executives who think “cloud migration” is something you do over a weekend.

Here’s what I wish the people making acquisition decisions understood:

Include engineers in due diligence. Not a CTO doing a handshake tour — actual engineers who can assess the technology estate, identify the integration challenges, and estimate the real cost. A week of engineering time during due diligence can save millions during integration.

Budget for 3x your initial estimate. Whatever number the consulting firm puts in the integration plan, triple it. Technology integration always costs more and takes longer than expected. Always. I’ve never seen an exception.

Retention is the real risk. The acquired company’s best engineers are the ones who understand the systems you just bought. They’re also the ones most likely to leave when you announce that their platform is being deprecated. If they leave before the migration is complete, you’re migrating a system that nobody understands. Invest in retention — and not just with money. Give them meaningful roles in the integration. Let them influence the target architecture. Make them part of the solution, not victims of it.

“Let them run independently” needs a hard deadline. Phase 1 is comfortable and expensive. Set a deadline, staff the integration team, and start the work. The longer you wait, the more the platforms diverge, the harder the integration becomes, and the more it costs.

The unsexy truth

Post-merger technology consolidation is dull as ditch water. There are no conference talks about it. No one’s writing breathless blog posts about the exciting world of identity federation across Azure AD tenants. It doesn’t make the CTO’s keynote because it’s not a “transformation” or a “modernisation” — it’s just hard, unglamorous work that has to happen when two companies become one.

But it’s also one of the most consequential technology challenges a large organisation will face. Get it wrong and you’re running two of everything indefinitely, haemorrhaging money and burning out the engineers who have to maintain it all. Get it right and you’ve built a unified platform that the combined organisation can actually build on.

Most organisations get it wrong. Not because the engineering is impossible, but because the people making the decisions don’t understand the problem, don’t budget for the solution, and don’t listen to the engineers who do.

If you’re about to go through an acquisition — on either side — find the most experienced platform engineer you can and put them in the room where the decisions are being made. They’ll tell you things the consultants won’t. And you’ll thank them later, even if you don’t enjoy hearing it at the time.