In this article:

Post-Merger IT Integration: The Playbook That Protects the Deal Model

M&A
/
August 20, 2026
Post-Merger IT Integration: The Playbook That Protects the Deal Model

Post-merger IT integration is the workstream that determines whether the synergies in the deal model ever reach the P&L. The sequence that works is consistent across deals: secure and connect on Day 1, stabilize identity and communications in the first 30 days, make the systems consolidation decisions by Day 100, and execute against the TSA clock, because every month on a transition services agreement is money paid to the seller for the privilege of not being integrated yet. Most integration failures trace to two mistakes made early: treating IT as a support function that follows the org design instead of a workstream that gates it, and underestimating data migration, which is the longest pole in nearly every integration tent.

The TSA is your real deadline

If the deal is a carve-out, the transition services agreement defines the entire schedule. The seller is contractually obligated to run email, ERP, payroll, or infrastructure for a defined period at a defined cost, and both the cost and the seller's patience escalate at renewal. Read the TSA as a project plan: every service schedule is a system you must stand up or migrate before its exit date, and the penalty rates on extensions tell you which exits the seller expects you to miss. Sequencing against TSA exits, rather than against an org chart, is what separates integrations that finish from integrations that pay rent forever. We cover the seller-side mechanics in our guide to the IT carve-out, and the same schedule discipline applies from the buyer's chair.

Pick the integration model before picking any system

There are three honest models. Absorption: the target moves onto the acquirer's stack, full stop. It is the cheapest to run afterward and the most disruptive during, and it is the right default when the acquirer is much larger and the target's systems carry no differentiating capability. Best-of-breed: system-by-system selection of whichever side runs the better platform. It produces the strongest end state and the longest, most political integration, because every selection is a turf fight. Coexistence: the target keeps its stack behind an integration layer, common in platform roll-ups and when the target will operate as a standalone brand. It is the fastest to Day 1 and the most expensive to run for years, and it quietly becomes permanent unless someone owns the consolidation roadmap.

The mistake is not choosing any particular model. The mistake is not choosing, and letting fifty system decisions get made one meeting at a time by whoever argues longest. Write the model down in the first two weeks, get the integration steering committee to sign it, and let it settle 80 percent of the system questions by policy instead of by combat.

Day 1: security first, then connectivity

Day 1 requirements are narrower than teams fear: people get paid, customers get served, email flows, and the security perimeter holds. The security item deserves the emphasis, because acquisitions are attack magnets. Threat actors read deal announcements too, and the integration window, with its rushed access grants, unfamiliar domains, and invoice-change confusion, is prime territory for business email compromise and lateral movement from the weaker environment into the stronger one. Before any network trust is established, the acquirer needs an honest read on the target's security posture, and the deal team should have bought that read during diligence. Inherited security debt is real integration cost: unpatched estates, flat networks, and orphaned admin accounts all get more expensive to fix after the domains are joined.

The workstreams and their real durations

A typical mid-market integration runs seven workstreams in parallel. Identity and access: directory consolidation, SSO, and email migration, usually 60 to 120 days, and the gate for almost everything else. Infrastructure and network: connectivity, then rationalization of data centers and cloud accounts. Applications: rationalize the portfolio, which in practice means killing duplicates, and the license review that goes with it, because change-of-control clauses and true-ups routinely add six and seven figure surprises. ERP and finance: the consolidation decision that dominates the budget, and the one worth staging rather than rushing, since a botched ERP cutover can take the close process down with it. Data: migration, quality remediation, and the reporting layer that lets leadership see the combined business, reliably the most underestimated line. Security and compliance: joining the acquired environment to the control framework, with certifications rescoped. And the integration management office itself: decision log, dependency map, and TSA exit tracking.

Staff the data workstream with your best people, not your available people. Every synergy report, every combined customer view, and every finance close depends on it, and it is the workstream where optimistic estimates fail by multiples rather than percentages.

Synergies come from decommissioning, not from integrating

IT synergies in the deal model usually assume consolidated licenses, retired systems, and reduced infrastructure spend. None of that lands until something is actually turned off. Track a decommissioning ledger from the start: every system with an owner, a retirement date, and the run-rate saving attached, reviewed monthly against the synergy commitments in the model. Integrations that skip this discipline end up running both stacks indefinitely, which shows up as negative synergy: two ERPs, two security tools per category, and an IT budget larger than the two standalone budgets were. The ledger is also the honest scorecard for the board, because it converts integration progress from activity reporting into dollars.

People decisions gate system decisions

Retention in the target's IT team is an integration asset with a short shelf life. The people who know where the undocumented dependencies live start interviewing the day the deal is announced, and the systems knowledge that walks out in month two gets rebuilt at consulting rates in month nine. Decide quickly who runs the combined function, name the keepers, and put retention agreements where the knowledge concentration is highest, typically the ERP administrators, the senior infrastructure engineers, and whoever owns the integration middleware nobody else understands. The broader people mechanics belong to the integration program at large, and they are the reason most mergers fail on the people side rather than the technical one.

The first 100 days, compressed

By Day 30 you want identity and email stabilized, the integration model signed, the application inventory complete, and the TSA exit map built. By Day 100 you want the ERP decision made with a staged plan, quick-win consolidations executed, the decommissioning ledger running, and the data migration scoped by someone who has done one before. Our post-merger integration 100-day plan covers the full program cadence beyond IT, and the two documents are meant to run together: the 100-day plan sets the operating rhythm, and the IT workstream feeds it the decisions that everything else waits on.

What IT integration costs

The honest budgeting anchor is a range: IT integration typically consumes 1 to 3 percent of deal value for an absorption of a smaller target into a larger acquirer, and 3 to 7 percent when a carve-out, an ERP consolidation, or heavy data remediation is in scope. The variables that move you inside the range are the ERP decision, the number of TSA services, data quality in the target, and how much security debt the diligence found. Two line items get underestimated most often. License true-ups: change-of-control clauses give vendors a negotiation window, and enterprise agreements that looked settled get reopened at renewal with the combined entity's headcount in the denominator. And parallel running: every month both stacks operate is double infrastructure, double tooling, and double support, which is why the decommissioning ledger above is a budget instrument as much as a progress report. Whatever number the deal model carried, pressure-test it against the TSA exit map in the first 30 days, because that comparison is cheap in month one and unaffordable as an argument in month nine.

Where BD Emerson fits

BD Emerson runs post-merger IT integration for private equity portfolio companies and strategic acquirers: integration strategy and model selection, TSA exit planning, identity and infrastructure consolidation, ERP decision support, data migration, and the security work that keeps the integration window from becoming an incident. The same team does technology due diligence, which means the integration plan can start from what diligence actually found rather than from a fresh discovery exercise. If you have a deal signed or a TSA clock already running, our merger integration practice can tell you within weeks which exits you will make, which you will miss, and what it takes to change that answer.

About the author

Alan Rotenberg is the Managing Director of BD Emerson’s Technology practice. Alan advises clients on a wide range of matters including technology strategy, project management, cloud computing, data management, software architecture, and AI integration. An accomplished, hands-on leader with 20 years of experience, Alan has a deep understanding of all aspects necessary to building and running successful teams and projects, including in highly regulated industries.
Alan Rotenberg
Alan Rotenberg
Managing Director – Technology Practice