Post-acquisition technology integration: plan it during the due diligence

Post-acquisition technology integration fails most often for a reason that has little to do with technology: the plan was written after closing, by people who had not seen the systems, on a timeline set by the deal announcement. The diligence team spent weeks inside the target’s architecture and handed over a report organized by severity, the right order for reading it before a committee and the wrong one for an integration. In our audits for acquirers and buy-and-build platforms, the integration plan is a deliverable of the DD, built from the same evidence on the same calendar.

Here is what that audit has to capture, and what to do with it in the first ninety days.

The systems map and where the data models overlap

Every acquisition starts with two systems maps that do not exist. We draw the target’s during the audit, listing every application, where it runs, what it stores and what talks to what, including the spreadsheets and automations nobody calls a system. Then we lay it over the acquirer’s map.

The expensive overlaps are in the data model rather than the applications. Two CRMs can coexist for a year. Two definitions of a customer, two product catalogs with different hierarchies, two ways of recording a contract, cannot be reconciled by picking a tool; they need a decision about which model wins and a migration someone has to design. They set the integration timeline more than anything else.

Identity, access, and the contracts that block consolidation

Identity is the first system to merge and the one most often left for last. We document who has access to what in the target, which identity provider issues it, and how offboarding works, because the acquirer’s security baseline extends to these people on day one. A target running on shared credentials and personal admin accounts needs that fixed before anything else is connected, and the buyer should know the size of that job before signing.

Contracts come next. Hosting commitments, licenses tied to the target’s legal entity, data processing agreements that name a sub-processor, an exclusivity clause with a vendor the acquirer is about to replace: each can block a consolidation or put a price on it. We read them during the DD with the integration in mind, alongside the open source license review for the code-level equivalents.

Which product stays, and what gets retired

When the target overlaps the acquirer’s own product, somebody decides which one survives, usually whoever argues best in the first steering committee. We prefer it decided on evidence from the audit, meaning which codebase is cheaper to carry, which product the customers would notice losing, and which engineering team can still change its system without fear. We price the debt as in any acquisition; here the number goes into a retirement schedule rather than a price negotiation.

Retirement is a project, with customers to migrate and contracts to honor, and the plan should name the quarter when each retired system stops being paid for. A product that was "retired" and is still running two years later is the most common line we find in a platform’s cloud bill.

The people who hold the knowledge

The integration plan has a dependency no system diagram shows: the two or three engineers who can rebuild the target’s core from memory. We identify them during the audit, component by component, the way we assess key person risk in any deal, and hand the buyer a list of what each knows that nobody else does. The retention package follows from that list, and so does the knowledge transfer, with documentation before the integration starts, pairing on the pieces that will move, and a date after which the platform no longer depends on any one of them. Losing one of them in month four, after the bonus vests and before the transfer is complete, is the failure we see most; dating the transfer rather than the bonus prevents it.

The first ninety days: what to merge and what to leave alone

Do not merge codebases. Do merge monitoring, security baselines, and the commitments made to customers.

Codebases merge badly under deal pressure. The target’s engineers are learning a new employer, the acquirer’s a new system, and a merge started in that state produces a hybrid neither team owns. Monitoring is the opposite case: one view of both platforms, with shared alerting and on-call, costs weeks and prevents the outage that happened in the other company’s dashboard. Security baselines belong in the same window, with single sign-on across both companies, MFA everywhere, and secrets rotated now that outsiders have read the target’s repository history. Customer-facing commitments, SLAs, data residency promises, support hours, have to be reconciled before a customer notices the difference.

The three classic failures map onto these rules. Merging too early produces the hybrid nobody owns. Merging never produces a holding company that pays for two of everything and gets the synergy of neither. Losing the one engineer produces a product that cannot change. A diligence that captures the map, the overlaps, the contracts and the people prevents all three, and its findings come out ordered by what to do rather than by what they are worth. That is how we scope a technical due diligence for a buyer with integration in mind.