Signing is not the finish line: what breaks in the first 90 days of post-close IT

Six weeks into a post-close integration a few years back, I sat down with a CEO whose firm had just closed on a company about a third their size. The deal team had moved on. The integration team had moved on. He was on the hook for the operating result, and he was one week into discovering that the target's IT was not what the diligence deck had described.

He asked me what he should have asked before the deal closed. Fair question. Deserved a real answer.

What follows is the pattern I have watched play out across thirty-plus mid-market acquisitions on four continents, framed as a ninety-day operating window. Day 1, Day 30, Day 90. What breaks. What to have ready. What to stop assuming.

Day 1The first week

The first week is not integration. The first week is inventory, access, and payroll. In roughly that order.

Inventory means: what does the target actually run. Every mid-market target has three IT layers, not one. The documented stack (what the CIO says they run). The shadow IT (what departments actually use, often paid on a corporate card the CIO never sees). The technical debt (what still runs but nobody actively owns because the person who set it up left in 2019). Diligence usually catches the first. If you are lucky, it catches half of the shadow IT. It never catches the technical debt.

Access means: whose credentials still work, whose should not, and can you prove which is which. The number of post-close integrations where a former employee's VPN account is still active on Day 5 is higher than anyone wants to admit. That is a security problem before it is an IT problem.

Payroll means: on Friday, people expect to be paid. Whatever else breaks in week one, this cannot. Most targets run payroll on a system the buyer does not use. Do not touch it in week one. Document it, know the cutoff dates, plan the switch for month three at the earliest.

Day 30The first month

By Day 30, the shape of the actual integration problem becomes visible. Diligence said the target ran Microsoft 365. Turns out they run Microsoft 365 for email but Google Workspace for finance because the CFO's previous firm was on Google. Diligence said they had a DR plan. Turns out they had a DR document. Not the same thing. What made it into the deal room and what is actually running in production are almost never the same thing at mid-market scale.

Day 30 is where the buyer's integration discipline shows up. Three moves, in this order:

First, map every system to its lifecycle position. Product and hardware. End of life today, mid-lifecycle, or naturally sunsetting inside two years. That map determines what integration effort is even worth spending.

Second, integrate what is mid-lifecycle. Leave what is naturally sunsetting. A system that its own vendor is going to replace in eighteen months does not need a buyer-side integration project. Let the natural cycle finish. Redirect that budget to systems with five or more years of runway, because that is where the integration investment actually pays back.

Third, consolidate for business outcomes, not tidiness. The reason to unify anything is so leadership can see the combined entity as one entity: one view of revenue, one view of margin, one view of headcount and cost. Data consolidation for unified business decisions is the target. Stack consolidation for uniformity is a distraction that spends real money for a cosmetic win.

Two other things fall into place on Day 30. Consolidate the systems that create real risk if left alone (identity, security, backup) even if the lifecycle math is unclear. And name owners for every system in writing. By Day 30 the target's IT people are wondering if they still have jobs, and their productivity has dropped. If owners are not clear by end of month one, month two is chaos.

Day 90The first quarter

Day 90 is when the real cost of the integration becomes visible on a P&L. Not the budgeted cost, which was in the deal model. The actual cost, which was not.

The gap between the two is usually explained by four things. One: licensing overlap the diligence team did not catch, because the target had renegotiated a specific vendor deal that was not documented anywhere the buyer could see. Two: technical debt the target had deferred pre-close, from hardware refresh cycles to expired support contracts to end-of-life software, all now unavoidable. Three: cybersecurity work scoped as "post-close cleanup" that turns out to be a full posture rebuild. Four: staff time. Somebody has been running integration part-time for ninety days and their day job has not been getting done.

By Day 90, the buyer should be able to answer four questions in writing. What did integration actually cost, versus what we modeled. What is still open that will require dollars in the next two quarters. Are we now making decisions on unified data across the combined entity, or are we still stitching reports together manually. And what did we learn about our own integration playbook that we should apply to the next deal.

The pattern behind the three phases

Integration is a discipline, not an event. The buyers who succeed treat the ninety days after close with the same rigor they applied to the ninety days before it. The buyers who struggle treat close as the finish line, and then spend the first quarter re-learning what they should have staffed for from Day 1.

You cannot make Day 1 easy. You can make it survivable, and you can make Day 30 and Day 90 predictable. That is the actual job.

James

We have run this framework across acquisitions from Calgary to Bangkok, in mid-market operators, energy services, and industrial firms. If you are approaching a close and want the operating-side of the IT plan mapped, send us the deal shape at connect@vencergroup.com. Straight answer, no sales cycle.