Buy-and-build without the integration hangover

Bolt-ons are carrying the mid-market playbook this year. The deal model assumes the systems come together; here's how to make that assumption true.

The early 2026 deal tape confirms what most operating partners already felt: this is a selective market. Fewer platform deals are clearing, valuation gaps are stalling processes, and the activity that is happening skews heavily toward buy-and-build — bolt-on acquisitions onto platforms that already work.1

Which means, for a lot of portfolio companies, the value-creation plan now runs directly through a technology integration. Several of them, actually, in sequence.

Here's the pattern we've watched across dozens of these — including the ways it goes wrong.

The deal model is precise about synergies: consolidated back office, cross-sell, procurement leverage, a multiple re-rate at exit. The IT integration plan supporting all of that is, frequently, a single slide — and the slide says something like "systems integration: months 6–18."

That's not a plan; it's a placeholder where a plan should be. And it's expensive, because integration is where buy-and-build returns are actually won or lost. Synergies that exist in the model but not in the systems have a way of staying in the model.

The first discipline is sorting decisions by when they must be made — because the costliest mistakes come from getting the timing backwards.

Decide before close (or immediately after):

• Identity and email. Who's on what domain, who can access what, and how the two companies communicate securely from day one. Getting this wrong is how phishing finds its window.
• Financial reporting. The sponsor needs consolidated numbers from month one. That doesn't require one ERP; it requires a defined path from their ledger to your reporting.
• Security floor. The acquired company inherits your threat profile the day the press release goes out. MFA, endpoint protection, and backup coverage get extended immediately — not after the roadmap discussion.

Deliberately defer:

• ERP consolidation. The most expensive decision in the whole program, and the one most often rushed. Consolidating onto the wrong system — or at the wrong time — burns integration budget and operational goodwill in one stroke.
• The application long tail. Every acquired company runs tools the acquirer has never heard of. Some are leftover clutter; some are quietly load-bearing. You need a quarter of observation before you can tell which is which.

The second discipline is admitting there are three integration postures, not one — and choosing per bolt-on rather than by default:

Absorb. The acquired company moves onto your systems, full stop. Right when the bolt-on is small relative to the platform, operations overlap heavily, and its systems are nothing special.

Federate. Shared identity, security, and reporting; local operational systems stay put for now. Right when the bolt-on serves a distinct market or the deal thesis depends on capabilities its systems actually embody.

Leave alone. Consolidated reporting and a security floor, nothing more. Right when the hold is short, the business is genuinely different, or the integration cost demonstrably exceeds the synergy.

The expensive mistake is absorbing by reflex — because "one platform" sounds like discipline — when the economics point elsewhere. One platform at exit is often the right story; one platform by month six is often just a bonfire.

Ask anyone who's run a few of these what shows up mid-program, and you'll hear the same list. License true-ups, when vendors notice the entity change and re-read their contracts. Duplicated security and infrastructure tooling, each with its own auto-renewal. Key-person risk, when the one engineer who understood the acquired company's warehouse system takes a package. And orphaned legacy applications — systems already past their support dates that nobody flagged in diligence, now your compliance problem. (If retirement-date vocabulary isn't second nature, our plain-English guide to EOL and EOS was written for exactly this.)

Every one of these is findable in the first 30 days. Few of them are found, because nobody owns the finding.

A diligence report describes what exists. It can't sequence decisions, sit in the vendor meetings, or tell a CEO which of two ERPs should win — that takes an operator who has done it before, embedded long enough to matter but not a headcount forever. That's the seat a fractional CIO fills in a buy-and-build program: the named owner of the slide that used to say "TBD."

We've written up one example in detail — a PE-backed, acquisition-led energy services firm that needed a straight answer to a simple question before the next bolt-on: can the platform scale? The answer shaped the roadmap. It usually does.