You don't inherit a tech stack. You inherit four of everything.
Picture the first integration planning session after a four-entity roll-up closes. Somebody pulls the consolidated SaaS spend into one spreadsheet and the room goes quiet. Four CRM instances. Six BI tools, each with its own "source of truth" dashboard. Nine separate places people send each other messages. In one tech-enabled services roll-up we worked through, the combined environment ran 342 distinct applications — and not one human in the building could name them all.
The reflex from the incumbent IT leadership is almost always the same: a "phased consolidation" targeting something safe, like an 18% reduction over 24 months, framed as protecting morale at the newly acquired companies. It sounds responsible. It is actually the most expensive option on the table, because every month of overlap is a month you pay full freight on duplicate licenses, duplicate security monitoring, duplicate vendor-management hours, and a larger attack surface than the deal model ever priced in.
The waste is not a rounding error. Flexera's state of IT management research consistently finds that roughly a third of total IT spend goes to SaaS that is duplicated or simply never used. That's the steady-state figure for a single company that grew organically. Stack four acquisitions on top of each other and the redundancy compounds — you didn't add 20% more apps, you added a second, third, and fourth copy of the same capabilities. That is why "20% reduction" is the wrong frame for a roll-up. In a multi-entity platform, a 50-to-60% reduction isn't aggressive. It's just deleting the duplicates. We've broken down where this leak hides in The 'Inactive License' Tax: Why 27% of Your Acquired Tech Stack Is Burning Cash.
Kill, Migrate, or Federate — and the 90% rule that decides
Every one of those 342 apps lands in exactly one of three buckets, and the sorting has to be ruthless because the moment you debate, you lose. Kill the app when it's a duplicate of a platform-standard tool — shut it off on the migration date, with no data carried forward beyond a read-only archive. Migrate it when it holds data or workflow you need but the capability already exists in the standard, so you move users onto the standard and decommission the source. Federate it only when it does something genuinely unique and integration-grade — a regulated billing engine, a niche industry tool with no real substitute — so you wrap it in an API and leave it alone instead of forcing a bad migration.
The tiebreaker is the 90% capability rule. If the platform standard covers 90% of what an acquired app does, the acquired app is a Kill — full stop. The 10% gap is almost never worth a parallel system; it's worth a workaround and a quarterly review. The trap is letting a business unit argue that their project tool is "fundamentally different." It almost never is. Three of those four CRMs in our example weren't different products doing different jobs — they were the same job, configured by three different admins who'd never met.
This is where you find the real money, because the right move is often to pay to make a contract go away early. Say an acquired company is 34 months into a $500K-a-year platform you're killing. A 15% breakage penalty is real cash out the door — and it is still dramatically cheaper than carrying the full OpEx for the remaining term while the tool sits unused. Run that math app by app and the recovered run-rate adds up fast; in the roll-up above, the consolidation pulled roughly $4.2M back into annualized EBITDA. The cost of not consolidating is just as real: Gartner's work on application modernization ties a fragmented post-M&A portfolio to materially higher integration-complexity costs over a multi-year hold — costs that show up as missed launch dates and headcount you only hired to keep the lights on. The sequencing playbook is in The Vendor Consolidation Playbook: How to Cut 30% of IT Spend in 100 Days Post-Close.
The cutover is a calendar decision, not a campaign
Here is what most integrations get wrong about the last mile: they treat decommissioning as a persuasion problem. Reminder emails. "Please migrate by end of month." A change-management deck. People do not leave a tool they like because you asked nicely — they leave when the tool stops working. So you make the retirement a hard date in your Identity and Access Management config: on the scheduled day, you remove the Single Sign-On route to the retired app. Login simply fails over to the standard. Expect a spike in helpdesk tickets that week — staff it, write the FAQ in advance, and have the migration support ready — but do not move the date. Moving the date once teaches every team that the schedule is negotiable, and your 60% target quietly decays back to 18%.
The reason any of this is worth the friction is that killing the app kills the shadow process behind it. When the acquired sales team logs into the parent's CRM because their old one no longer exists, they inherit the parent's pipeline stages, forecasting cadence, and discount-approval rules along with it. That's how the synergies in the deal model actually land on the P&L instead of staying on a slide. Bain & Company's M&A integration research points the same direction — acquirers who consolidate aggressively capture meaningfully more synergy in the first year than those who let each entity keep its own stack. And buyers at your eventual exit will run technical diligence; a clean, unified architecture reads as a platform, while four-of-everything reads as a holding company that never integrated.
If you do one thing Monday: pull every SaaS and software contract across the acquired entities into a single sheet with renewal date, annual cost, and a one-word bucket — Kill, Migrate, or Federate. Sort by renewal date. The contracts renewing in the next 90 days are your first wave, because those need a non-renewal decision now, not a migration plan later. For the apps you mark Federate, the integration mechanics matter as much as the decision — that's covered in The 'Frankenstein' Platform: Why API Federation Is the Only Viable Integration Strategy for PE Roll-Ups. Consolidate deliberately, standardize on a calendar, and treat the duplicate-app count as a number you own from Day 1.
