What a post-acquisition integration actually costs when nobody's watching.
Three real engagements, three different industries, the same underlying pattern: the deal closes, and the integration debt starts compounding immediately — invisibly, until someone goes looking for it.
The deal is the easy part
Due diligence gets months of attention. Integration gets a plan on a slide and then whatever time is left over after the deal actually closes. That imbalance is the source of almost every post-acquisition problem — not bad diligence, not a bad target, just a structural underinvestment in the unglamorous work of making two organizations run as one.
The three engagements below span industrial refrigeration, automotive consulting, and fuel delivery — different industries, different buyers, different deal sizes. The pattern underneath all three was identical.
Three engagements, one pattern
20+ acquisitions, 20+ separate systems, and no one accountable for the pattern repeating
Each new acquisition arrived with its own database, its own commission process, its own way of doing things — and every deal made the integration debt worse before the last one had even been resolved. Serving as Fractional CIO, the fix wasn't reactive cleanup after each deal. It was building a structure every future acquisition could be folded into cleanly, before the next deal closed.
New ownership couldn't see the business it had just bought
The instinct after acquiring a company is often to replace its systems outright — a clean slate. Here, the faster and cheaper path was extending the life of the ERP system already in place, giving new ownership real visibility into sales, operations, and financial reporting without the cost and disruption of a full system replacement and the retraining that comes with it.
A $100M operation running on habits nobody had actually examined
Not every integration follows a single acquisition — sometimes it's a mature operation that's simply never had its underlying logistics, incentives, and inventory processes examined together. Reengineering the $100M transportation operation, realigning sales incentives with actual logistics costs, and fixing inventory turnover produced results across every part of the business it touched.
Read the delivery case study → · Read the inventory case study →
The common thread
In each case, the instinct under pressure was to move fast on something visible — replace the system, roll out new software, consolidate everything at once. In each case, the actual fix was slower and less dramatic: understand what was really happening operationally first, then make the technology decision in service of that, not ahead of it.
That sequencing is what separates an integration that compounds problems from one that resolves them. A new system layered onto an unclear process just makes the unclear process run at a larger scale.
- Can you currently produce one clean, current view of the acquired business — or does it take pulling from multiple disconnected sources?
- Is anyone specifically accountable for the integration itself, or is it everyone's job in theory and no one's in practice?
- Before replacing a system, have you confirmed it's actually the system that's broken — or just under-configured for what the combined business needs now?
- Does the plan account for the next acquisition, or only the one you just closed?
Mid-integration and not sure what's actually broken?
Six questions, two minutes — or just tell us where things stand and we'll help you figure out what to fix first.
Take the readiness check Talk to us