How to Integrate IT Systems After an Acquisition

Most acquisition checklists treat IT as a single line item. "IT integration" gets assigned to someone, a timeline gets estimated, and the assumption is that it gets handled. Then the deal closes and the real picture emerges.

The acquired business runs a different EHR. Their network wasn't documented. Their security hasn't been assessed. Their software licenses aren't transferable. And your opening date is in six weeks.

This happens regularly. It doesn't have to.

What IT Integration After an Acquisition Actually Involves

IT integration isn't a single project. It's a sequence of projects that have to happen in the right order, across multiple vendors, against a deadline that usually doesn't move.

The work typically breaks into four phases:

Pre-close assessment. Before the deal closes, someone needs to look at what's actually there. Network infrastructure, endpoints, servers, software licenses, security posture, and any systems that need to connect to the acquiring organization's infrastructure. This is IT due diligence, and skipping it is one of the most expensive mistakes acquirers make.

Network and connectivity standup. The acquired location needs to connect to the parent organization's network. This might mean installing new firewall hardware, establishing VPN connectivity, or a full network rebuild depending on what's there. Cabling contractors may need to be scheduled. This step has dependencies -- nothing else works until connectivity is established.

Identity and systems integration. Users need accounts in the right systems. Directory services need to be federated or migrated. Business applications need to be configured. If there's an EHR or practice management system that's changing, that migration needs a plan, a testing phase, and a go-live with clinical support standing by.

Go-live and stabilization. The cutover day is when things either work or don't. Having someone onsite who knows the integration plan and can make decisions in real time is the difference between a clean go-live and a chaotic one. The two weeks after go-live are when the issues that weren't caught in testing surface. That window needs coverage too.

What Goes Wrong Most Often

IT integration fails or runs over in predictable ways. The same problems come up repeatedly.

No one assessed the target before close. This is the most common and most expensive failure. Issues that would have been negotiating points or walk-away signals get discovered post-close when you own the problem.

The timeline was built without understanding the dependencies. Cabling contractors have lead times. Equipment ships on vendor schedules, not yours. Network configurations take longer when the environment is poorly documented. A realistic integration timeline works backward from go-live and accounts for all of it. An optimistic one doesn't.

Nobody owned the vendor coordination. A typical integration touches a dozen vendors -- network hardware, ISP, phone system, EHR, endpoints, security software. When nobody is specifically accountable for keeping all of those relationships moving in the same direction, things fall through the gaps.

The clinical or operational staff weren't involved early enough. The people who use the systems every day know things about the workflow that don't show up in a technical assessment. Getting their input before the integration plan is finalized prevents a category of problems that only surfaces after go-live.

Building a Repeatable Process

Organizations that do one acquisition figure it out as they go. Organizations that do five acquisitions figure out that they can't afford to keep doing that.

A repeatable integration playbook is worth building after the second or third acquisition. It documents the assessment checklist, the vendor contact list, the network standup sequence, the go-live checklist, and the stabilization criteria. It captures what was learned from each integration so the next one starts smarter.

The first integration built from a documented playbook is noticeably faster and cheaper than the previous one. The second is faster still. By the fifth or sixth, integration is a known quantity rather than a crisis each time.

The PE Context

For private equity-backed organizations with active acquisition pipelines, IT integration is a portfolio-level problem, not just a deal-level one. Every integration that runs over costs money. Every security gap that gets missed creates liability. Every system that doesn't integrate cleanly adds ongoing operational friction that compounds across the portfolio.

Operating partners who treat IT integration as a technical detail rather than a strategic function tend to find out why that's wrong somewhere around the third or fourth acquisition. The organizations that get it right earlier are the ones that bring in integration expertise before the playbook needs to be built under pressure.

What to Look For in an Integration Partner

IT integration experience in theory is common. IT integration experience across multiple actual acquisitions, with the specific systems your industry runs on, is much rarer.

Ask specifically about the integrations they've led, not the integrations they've supported. Ask about what went wrong and how they handled it. Ask about their due diligence process and what it typically surfaces. The answers tell you more than a capabilities deck.