By Mario Peshev, DevriX
Most IT integration failures in mid-market deals are not technical failures. They are underwriting failures. The diligence team priced a thesis that assumed two companies could operate as one, and nobody put a number on the systems work required to make that true. Six months post-close, the integration is late, the synergy case is slipping, and the deal partner is learning about a $2M ERP migration in a monthly report instead of in the model.
I have sat on both sides of this. I run a firm that gets pulled into portfolio companies after the technology surprises show up, and I have watched capable operating partners inherit an IT estate nobody scoped because it lived under the CFO’s “miscellaneous systems” line. The pattern is consistent enough that I want to be direct about what a deal partner or operating partner actually needs to decide when it comes to IT integration, and how to judge whether it is being done well.
This is not a CTO’s checklist. It is the operator’s frame: where IT integration touches enterprise value, what to underwrite before close, and what “good” looks like in the first year of ownership.
IT integration is a value-creation lever, not a cost line
The default treatment of IT in a deal is defensive. Keep the lights on, avoid a breach, don’t let the systems break during transition. That framing quietly caps the upside and hides the risk.
The truth is that IT integration sits directly on top of the synergy case in most B2B and services deals. Consolidated billing that lets you actually cross-sell across an add-on’s customer base. A single CRM that gives the operating partner real pipeline visibility instead of three incompatible exports. A finance stack that closes the books in five days instead of twenty-five, which changes how fast you can react to a covenant problem. Every one of those is EBITDA or cash-flow or management-visibility, and none of them happen without deliberate systems work.
So the first decision is a framing decision. Are you treating IT integration as a tax you pay to keep the business running, or as the mechanism that unlocks the reasons you bought the company? Bain’s annual Global Private Equity Report has tracked for years how much of the return story now depends on operational improvement rather than multiple expansion. When operational improvement is the thesis, the systems that carry operations are not overhead. They are the delivery vehicle.
I have written before that PE value creation requires embedded partners, not advisory firms, and IT integration is exactly the kind of work where a slide deck of recommendations dies on contact with a legacy database.
What to underwrite before you sign
The commercial diligence process is disciplined about revenue quality, customer concentration, and margin. IT diligence is too often a one-page vendor summary and a security questionnaire. That gap is where the money leaks.
Before close, you need answers to a specific set of questions, and each one maps to a dollar figure or a risk that belongs in the model, not in a footnote.
Is the target’s technology a liability disguised as an asset?
Custom software built by a founder-engineer who left two years ago. An ERP version that the vendor stops supporting next year. A “platform” that is actually a spreadsheet with a login page. These are the things that read as neutral in a data room and then demand seven figures of remediation once you own them. The same discipline I described in commercial due diligence red flags in B2B businesses applies here: the red flag is rarely stated, it is inferred from what the seller cannot show you.
How much of the synergy case actually depends on systems work?
If your model assumes procurement savings from combined purchasing, someone has to consolidate the purchasing systems. If it assumes headcount reduction in finance, someone has to consolidate the finance systems first. Map each synergy line to the integration work it requires, and put a cost and a timeline against that work. A synergy that depends on an eighteen-month systems migration is not a Year 1 synergy, and pretending otherwise poisons the whole forecast. This is the same rigor I argue for in adjusted EBITDA and the art of add-backs: a number is only as good as the work behind it.
What does the Transition Services Agreement really cover, and for how long?
In a carve-out, the TSA is the difference between a clean transition and a hostage situation. Sellers price TSAs to be uncomfortable so you exit them fast. If your integration plan runs longer than the TSA, you have a gap where the target has no functioning IT and you have no leverage. Underwrite the TSA exit as its own project with its own budget.
McKinsey’s private capital research and BCG’s principal investors work both consistently make the point that integration planning done before close, not after, is the single strongest predictor of whether deals hit their synergy targets. The IT piece is the part that most often gets deferred to “we’ll figure it out post-close,” and it is the part least forgiving of that approach.
The three scenarios and what each one costs you
Not all IT integration is the same job. The operator needs to know which of three fundamentally different situations they are in, because the cost, timeline, and risk profile of each is different.
The platform build
You bought a company to be the platform for a roll-up. The IT decision here is architectural: you are not integrating, you are building the chassis that future add-ons will bolt onto. Get the CRM, ERP, and data model right now, because every add-on you buy later will be cheaper and faster to integrate if the platform was designed to absorb them. Cheap decisions here compound into expensive ones across the whole hold.
The bolt-on absorption
You are adding a smaller company to an existing platform. The default should be absorption: kill the add-on’s systems, move its data and people onto the platform’s stack, retire its licenses. The cost is the migration and the change management. The risk is disruption to the acquired company’s operations and customers during the cutover. Speed matters here because every month of parallel systems is a month of duplicated cost and duplicated confusion.
The standalone hold
Sometimes the right answer is to leave the target’s IT largely alone, stabilize it, remove the acute risks, and not integrate at all because the exit thesis does not require it. This is a legitimate choice and often the disciplined one. The mistake is drifting into it by default rather than choosing it deliberately, then discovering at exit that a buyer marks you down for a fragile, unsupported estate you never fixed.
How to judge whether it is being done well
Once you own the company, the question shifts from “what did we underwrite” to “is the integration actually working.” Most operating partners are handed IT status reports full of activity: tickets closed, servers migrated, sprints completed. That is the vendor register, and it tells you almost nothing about whether value is being created.
Judge the integration on outcomes that map to the thesis:
- Is the promised synergy realized, run-rate, or still just forecast? A consolidated billing system that is live and processing is realized. One that is “on track for Q3” is forecast. Do not let the second read as the first in your reporting.
- Has management visibility improved? Can you now see consolidated pipeline, consolidated cash, and consolidated margin in one place? If the integration has run six months and you still cannot get a clean combined P&L, the integration is not serving its purpose regardless of how many systems moved.
- Has operating risk gone down? Fewer single points of failure, supported software versions, a security posture that will survive a buyer’s diligence. Risk avoided is real value even when it never shows up as a synergy dollar.
- Is the close faster and the forecast more reliable? A CFO who can close in a week and forecast with confidence is worth more than one who cannot, and buyers price that difference.
This is the same lens I apply to portfolio company operating reviews and the commercial KPIs that matter. The IT integration should show up in those reviews as commercial outcomes, not as a technical side-report the operating partner skims.
Where integration quietly leaks value
Even a competent integration bleeds value in predictable places, and the operator who knows where to look catches it early.
Duplicate spend that nobody retires
Two CRMs, two ERPs, two sets of licenses, two vendor contracts running in parallel long after the migration was supposed to end. This is pure duplicated cost, and it persists because retiring a system is nobody’s Monday priority. I covered the broader version of this in the B2B portfolio revenue leakage diagnostic. On the IT side, the leak is on the cost line and it is often invisible until someone audits the vendor spend against the integration plan.
Commercial systems that break the revenue engine
The most expensive integration failures I see are not in finance or infrastructure. They are in the commercial stack. A botched CRM migration loses pipeline history and the sales team flies blind. A marketing automation cutover drops the lead nurture and the funnel dries up. These directly hit revenue, and they are exactly why a fractional CRO focused on win rate and CAC should have a voice in how the commercial systems get integrated, not just the IT team.
Integration fatigue in the acquired team
Every system migration lands on people who still have their day job to do. Push too hard and you lose the operators who actually understand the acquired business. The soft cost of a badly sequenced integration is attrition of the exact people you needed to retain.
Who should actually own this
The most common structural mistake is assigning IT integration to whoever holds the CTO title at one of the two companies and calling it managed. IT integration is a cross-functional program that touches finance, sales, operations, and legal. It needs an owner with the authority to make trade-offs across all of them, which usually means the operating partner or an integration lead who reports to them, not a functional technical manager.
It also needs someone accountable to the P&L, not to a project plan. This is the distinction I keep drawing between value creation consultants and operators with P&L accountability. A consultant delivers an integration roadmap. An operator delivers a consolidated business. The deal did not buy a roadmap.
The reporting matters here too. The Harvard Law School Forum on Corporate Governance has extensive material on post-merger integration governance, and the recurring theme is clear ownership and clear escalation. Ambiguous ownership is where IT integrations stall, because every hard trade-off requires someone to decide whether operational disruption or delayed synergy is the lesser evil, and technical staff are not positioned to make that call.
Sequencing it against the first hundred days
IT integration does not sit in a vacuum. It competes for management attention and cash with everything else the operating partner is trying to do in the first year. The sequencing decision is as important as the integration decision itself.
My general rule: fix the things that stop the bleeding first, enable the highest-confidence synergy second, and defer the architecturally clean but low-urgency work until the business has absorbed the earlier changes. A finance consolidation that unlocks reliable reporting usually earns its place early because it makes every subsequent decision better informed. A full CRM re-platform, however desirable, can wait if the current setup is functional and the sales team is mid-quarter.
This is why I fold IT integration directly into the 100-day go-to-market plan for a newly acquired B2B business rather than treating it as a parallel technical track. The commercial plan and the systems plan are the same plan, because the systems exist to serve the commercial outcome. When they are managed separately, the IT team optimizes for a clean architecture and the commercial team optimizes for revenue, and the two collide in month four.
The pitfall I see most is treating IT integration as a Year 1 project that must be “finished.” Some of it should be, the acute risk and the high-confidence synergy. Much of it is properly a multi-year evolution that should track the hold thesis. I made a version of this argument about pacing and prioritization in private equity GTM and value creation pitfalls, and it holds for systems as much as for go-to-market.
What this looks like at exit
The final judge of your IT integration is the next buyer’s diligence team. Everything you did or deferred gets re-examined by someone deciding what your company is worth. A clean, consolidated, well-documented estate supports the multiple. A tangle of half-integrated systems, undocumented custom code, and unsupported software becomes a discount, because the buyer prices in the remediation they now have to underwrite exactly as you should have at the start.
This is the through-line I keep coming back to in work on future-proofing organizations: the decisions that look like technical housekeeping during the hold are enterprise-value decisions at exit. PitchBook and S&P Global data on hold periods and exit environments both point to the same reality, that buyers have grown more discerning and diligence more thorough. PitchBook research and S&P Global Market Intelligence track a market where a fragile technology estate is no longer something a buyer overlooks in a hot market, because the market is not reliably hot.
Judge your integration by the question you will face at exit: does the systems estate make this business easier to buy, or harder? Everything else is a proxy for that.
The decisions an operator actually owns
Strip away the technical detail and the operator’s job on IT integration comes down to a short list of decisions. Which scenario are you in, platform, bolt-on, or standalone. What does the synergy case genuinely depend on in terms of systems work, and is that priced in the model. Who owns the program with P&L authority. How does it sequence against everything else in the first year. And does the end state support the exit multiple.
None of those are technical questions. They are underwriting and value-creation questions that happen to have technical answers. The failure mode is delegating the questions along with the answers, handing the whole thing to an IT function, and being surprised when the integration serves a clean architecture instead of the deal thesis.
IT integration done well is quiet. The systems consolidate, the reporting sharpens, the synergies land on schedule, and the exit diligence goes smoothly. Done badly, it is a slow leak that shows up first in delayed synergies, then in management blind spots, and finally as a discount in the sale. The difference is almost entirely in how it was scoped and owned, decisions the operator makes long before the first server moves.
Where to take this next
If you are staring at a deal where the IT estate is a question mark, or a portfolio company where the integration has stalled and you cannot tell whether it is on track, that is exactly the gap we close. We embed with operating partners and portfolio management to translate systems work into the financial and commercial outcomes the deal was built on, and to own the parts of it that require someone accountable to the P&L.
You can start an advisory exploration with me here to pressure-test your integration thesis before or after close, or review how DevriX works with portfolio companies on the systems and commercial execution that carry it. The best time to scope the IT integration is before the LOI. The second best time is now, before the leak gets priced into your exit.
