Why Stack Consolidation Projects Almost Always Under-Deliver

Somewhere in most companies’ history is a “tool rationalization” initiative that got kicked off with a spreadsheet of thirty-some tools, a target of cutting that number in half, and a projected savings figure that made the project look obviously worth doing. A year later, the tool count usually did come down, but the savings rarely matched the projection, the remaining tools rarely feel meaningfully more coherent, and a handful of the “eliminated” tools have a way of quietly reappearing under a new name within eighteen months. Understanding why consolidation projects consistently under-deliver says more about how these projects are scoped than about any particular failure of execution.

The Spreadsheet Audit Counts License Cost, Not Actual Dependency

Most consolidation projects start with a license audit: pull every tool with an active contract, sort by annual spend, and start asking which ones can be cut. This is the easiest data to gather and the least useful for the actual decision, because license cost tells you almost nothing about how deeply a tool is wired into daily workflows. A tool costing eight thousand dollars a year that three teams depend on for a step they can’t easily replace is a much harder cut than a forty-thousand-dollar tool that one team uses out of habit. Projects that sort by cost first end up cutting the easy, cheap, deeply-embedded tools and keeping the expensive, lightly-used ones, because cost is what got measured and dependency wasn’t.

Migration Cost Is Almost Always Underestimated by the Team That Isn’t Doing the Migrating

The business case for consolidation is usually built by someone in finance, ops, or procurement, comparing license fees before and after. The actual work of migrating workflows, retraining users, and rebuilding whatever automation depended on the eliminated tool falls on a different team entirely, and that team’s time is rarely priced into the business case with any rigor. A consolidation that looks like a clean win on a cost spreadsheet can quietly cost more in engineering and change-management hours than the license savings ever recover, especially when the eliminated tool had years of accumulated configuration, custom fields, or workflow logic that has to be manually rebuilt in the consolidated replacement rather than simply exported.

Shadow Usage Survives the Official Cutoff Date

Announcing that a tool is being deprecated and actually getting every user off it are two different events, often separated by months or longer. Whoever built a critical process around the “eliminated” tool has strong incentive to keep a quiet workaround running rather than lose their workflow, and unless someone is actively monitoring for continued usage after the official cutoff, that workaround simply persists, sometimes indefinitely, alongside the new consolidated system it was supposed to be replaced by. The company ends up paying for both, which is worse than the fragmented state the project was meant to fix, because now there are two systems doing the same job with no clear owner of which one is authoritative.

Consolidation Targets the Wrong Layer of the Stack

A lot of consolidation effort goes toward the tools that are most visible — the ones with a line item everyone recognizes on the vendor list — rather than the tools that are actually driving the most integration complexity. A handful of small, cheap, single-purpose tools each doing one narrow job usually cause less structural harm than two overlapping platforms both trying to be the system of record for the same category of data. Cutting the small tools produces a satisfying reduction in the tool count without touching the actual source of confusion, which is why a “successful” consolidation project can leave a team just as confused about where a given piece of data actually lives as before the project started.

Consolidation Approach	What It Optimizes For	What It Tends to Miss
Cost-sorted license audit	Visible annual spend	Operational dependency depth
Redundancy-mapping by function	Overlapping systems of record	Cheap tools with narrow, real value
Usage-frequency audit	Actively-used vs dormant tools	Seasonal or quarterly-only tools
Owner-led rationalization	Political buy-in from each team	Objectivity — owners defend their own tools
Full dependency mapping	Actual downstream breakage risk	Takes longer, often gets cut for time

The Political Cost of Cutting a Tool Someone Championed

Every tool in a stack has, somewhere in its history, a person who fought to get it approved, built processes around it, and has a reputational stake in it having been the right call. Proposing to eliminate that tool isn’t a neutral technical decision from that person’s perspective, and consolidation projects that don’t account for this political dimension routinely underestimate how much resistance a “logical” cut will generate. The tools that survive consolidation rounds are frequently not the ones that are most technically justified, but the ones whose owners have enough internal standing to successfully defend them, which is a very different selection criterion than the one the project claimed to be using.

Measuring Success by Tool Count Instead of Coherence

The most common structural mistake is defining success as a reduction in the number of tools rather than an improvement in how cleanly data moves between the tools that remain. A stack that goes from thirty tools to eighteen but still has three separate systems each claiming to be the source of truth for contact records hasn’t actually solved the problem consolidation was meant to solve — it’s just done it with fewer vendors. Tool count is easy to report to leadership and genuinely does correlate with cost, but it’s a proxy for the underlying goal, not the goal itself, and optimizing directly for the proxy is exactly how a project can hit its stated target and still leave the operational reality basically unchanged.

What a Consolidation Project Needs to Actually Deliver the Projected Savings

The projects that do deliver close to their projected value tend to share a specific discipline: they map actual data dependencies before deciding what to cut, they assign a real cost estimate to migration effort rather than treating it as a rounding error, they build in a hard cutoff with active monitoring for shadow usage rather than a soft deprecation date, and they measure success by whether a specific piece of data now has exactly one authoritative home instead of by how many logos got removed from the vendor list. None of that is complicated, but it requires more patience and more cross-functional coordination than the version of the project that just sorts a spreadsheet by cost and starts cutting from the bottom.