The average enterprise runs 364 separate SaaS applications. Managing those vendor relationships alone — not the licences, just the management overhead — consumes 15 to 20 percent of total IT operating expense. 68 percent of CIOs are now making consolidation their top priority. The great SaaS experiment is over. The bill has arrived.
For most of the past decade, adding a new SaaS tool to solve a specific problem was considered smart, agile thinking. Someone in marketing needed a better email tool. Someone in sales wanted a prospecting platform. A developer wanted a particular code review tool. The monthly subscription cost was low enough to bypass procurement controls, the onboarding took hours rather than months, and the individual productivity gain was visible and immediate. None of these were bad decisions in isolation. A thousand of them stacked on top of each other, accumulated across departments, mergers, and headcount cycles, have produced a problem that is now sitting at the top of almost every CIO's and CFO's agenda — and that most organisations are only beginning to understand the full cost of.
The numbers are striking once you actually count them. The average mid-market company in 2025 used 211 distinct SaaS applications. The average enterprise used 364. With an average of 7.6 applications entering technology environments each month, software portfolios are growing at over 33 percent annually. And here is what makes this more than a complexity problem: the total cost of vendor management — not the licensing cost, but the cost of managing the vendor relationships — had reached fifteen to twenty percent of total IT operating expense at large enterprises. That figure does not appear on any SaaS vendor's invoice. It lives in the accumulated time of IT staff renewing contracts, completing security reviews, maintaining integrations, managing SSO configurations, and handling the support escalations of dozens of tools that each work slightly differently and break in their own unique ways.
The recognition of this problem has reached a threshold that is changing procurement behaviour in ways that affect every technology vendor and every organisation evaluating its software portfolio. 68 percent of CIOs are already planning consolidation initiatives, with a majority of organisations targeting a 20 percent reduction in vendor count. The era of best-of-breed everything is giving way to what analysts are calling the great re-bundling — and the organisations that understand what is actually driving it will make significantly better technology investment decisions than those who interpret it as simply a cost-cutting exercise.
The SaaS portfolio that felt like agility in 2019 has become the operational complexity that is consuming IT budgets in 2025 — and the CIOs who recognised this earliest have already begun the consolidation programmes that their peers are now scrambling to catch up with. Image: Unsplash (free for commercial use — download and host locally before publishing).
How SaaS Sprawl Actually Happens — and Why It Is Nobody's Fault
The tempting explanation for SaaS sprawl is that someone failed to maintain governance. The honest explanation is more uncomfortable: SaaS sprawl accumulated over years for understandable reasons. Business units bought tools to move faster. IT teams enabled experimentation during growth phases. Mergers brought duplicate platforms. Pandemic-era urgency favoured speed over standardisation. No one made a single bad decision. Hundreds of reasonable decisions added up to an unreasonable outcome.
The structural problem is the mismatch between how SaaS purchasing happens and how SaaS costs accumulate. A monthly subscription at £49 per user does not trigger a purchase order in most organisations. It goes on a corporate card, gets categorised as a miscellaneous software expense, and disappears into an accounting line that nobody reviews with the same rigour applied to a capital purchase. Multiply that pattern across a hundred teams, each solving their specific problems with their specific tools, and the aggregate is a software portfolio that IT cannot fully inventory, security cannot fully audit, and finance cannot fully reconcile.
Companies with fewer than 500 employees are using more than 150 SaaS tools, with many enterprises running even more. SaaS sprawl often comes from conflicting directives — the CFO and CIO enforce policies requiring approval for new app purchases, while lower-level managers encourage employees to experiment and be problem solvers. The result is exactly what you would expect when an organisation sends contradictory signals: employees do both, and the tool count grows regardless of what the policy says.
Shadow IT Has Grown Up — and Got a Lot More Expensive
Shadow IT used to mean someone installing unauthorised software on their work laptop. In 2025 it means a department head signing a multi-seat SaaS contract on a corporate card that IT discovers six months later when the integration breaks something downstream. The scale has changed. The underlying dynamic has not: people buying tools to solve real problems, outside a governance process they experience as too slow to be useful.
Research shows that fragmented tech stacks can result in up to 36 percent higher total cost of ownership compared to unified platforms, with much of that cost hidden in integration overhead and operational complexity. That integration overhead is the shadow cost of SaaS sprawl that almost never appears in licence cost analyses. Every tool that needs to talk to the CRM, the ERP, or the data warehouse requires an integration that someone has to build, maintain, and fix when it breaks. At scale, this integration mesh becomes one of the most significant and least visible drains on engineering and IT capacity in the organisation.
Shadow IT in 2025 is not rogue employees installing unauthorised software — it is department heads signing multi-seat SaaS contracts outside IT governance, creating integration debt and security exposure that accumulates invisibly until it becomes a crisis. Image: Unsplash (free for commercial use — download and host locally).
The Hidden Costs Nobody Puts in the Business Case
When a team requests a new SaaS tool, the business case they present typically includes the licence cost and a productivity estimate. It almost never includes the full set of costs that the tool will generate over its lifecycle — and the gap between the stated cost and the real cost is where the SaaS tax lives.
Security review costs are the first omission. Every new SaaS tool that accesses company data requires a vendor security assessment, a data processing agreement review, and potentially a GDPR or SOC 2 compliance check. 89.4 percent of IT leaders surveyed have concerns about the security risks associated with AI tools specifically — and the same concern applies to any tool accessing sensitive business data. At large organisations, a thorough vendor security review takes between 20 and 40 hours of specialist time. Multiply that by dozens of new tools per year and the cost is significant — and it recurs annually as certifications expire and need revalidation.
Integration maintenance is the second omission. APIs change. SaaS vendors update their platforms on their own timelines, not yours. Every time a vendor makes a breaking change to their API, someone has to fix the integration that your data pipeline depends on. In organisations with mature integration meshes — where dozens of tools are connected to each other through a combination of native integrations, middleware platforms, and custom code — this maintenance burden is continuous and unpredictable.
Training and onboarding is the third. Developer training and onboarding can revolve around one set of tools rather than a multitude of offerings — but only when the tool count is managed. When every team uses different tools for similar functions, new employees face a learning curve that is multiplicative rather than linear. The productivity loss of onboarding to a fragmented tool environment is real but essentially invisible in the standard cost models organisations use to justify software purchases.
Licence waste is the fourth and the most immediately quantifiable. Inactive users, dormant accounts, and premium-tier users not using premium features represent spending that could be eliminated with basic portfolio management. Zylo's analysis of their customer base found that a significant proportion of SaaS licences in most enterprise environments are either unused or significantly underutilised — meaning the organisation is paying for access that nobody is consuming.
Why the Obvious Solution — Just Cut Tools — Usually Makes Things Worse
The instinctive response to a SaaS sprawl audit is to cut aggressively. The CFO flags the cost. Leadership sets a target. A list of tools is compiled. Contracts are cancelled. Early dashboards show savings. And then, six to twelve months later, the organisation discovers that the tools it decommissioned were more embedded in actual workflows than anyone realised — and that the employees who depended on them have either rebuilt the lost functionality manually or, more commonly, quietly adopted new unapproved tools to fill the gaps.
Removing tools without redesigning the process creates invisible costs that finance dashboards never capture. True optimisation requires understanding what breaks when a tool disappears. This is the insight that separates successful consolidation programmes from expensive disruptions dressed up as efficiency initiatives. The question is not which tools cost the most. The question is which tools are genuinely embedded in critical workflows, which have overlapping functionality that could be consolidated without losing value, and which are genuinely redundant in ways that allow clean decommissioning without downstream consequences.
Establishing target states across business domains is critical for reducing tool sprawl. A target state defines the strategic tool selected for a particular domain. Without a target state for each domain, the tendency is that another tool will get acquired for that team or that use case. The consolidation programmes that work are built on domain-by-domain rationalisations with clear, documented target states — not organisation-wide mandates to reduce vendor count by a specific percentage, which optimise for the metric while ignoring the operational consequences.
The AI Readiness Dimension That Changes the Consolidation Calculus
90 percent of IT professionals identified software consolidation as a priority, with 73 percent predicting their organisations will continue growing software investments while simultaneously consolidating vendors. This paradox — expanding capabilities while reducing complexity — defines the modern CIO's challenge. The resolution of this paradox is the AI readiness dimension: organisations are consolidating their general-purpose SaaS portfolios specifically to free up the budget, the integration capacity, and the data governance attention required to invest seriously in AI.
Fragmented SaaS environments are, structurally, poor environments for AI deployment. AI systems need clean, accessible, consistently defined data to function effectively. When that data is distributed across 200 tools with 200 different schemas and 200 different API access patterns, building the data layer that AI requires is an enormous and expensive engineering challenge. Organisations that have rationalised their SaaS portfolios around a smaller number of integrated platforms discover that their AI data foundation is significantly cleaner and more accessible — because there are fewer systems to integrate, fewer data definitions to reconcile, and fewer integration points to maintain.
SaaS consolidation and AI readiness are the same investment viewed from different angles — organisations that rationalise their tool portfolios create the clean, integrated data environment that AI deployment requires, while simultaneously reducing the operational overhead that was consuming IT capacity. Image: Unsplash (free for commercial use — download and host locally).
The Vendor Consolidation Trap Nobody Talks About
There is a risk on the other side of the consolidation pendulum that is receiving less attention than it deserves: vendor lock-in at a scale that creates its own strategic vulnerability. SaaS prices for mission-critical systems including ERP, CRM, and data platforms have risen significantly. Vendors are justifying subscription price hikes with frequent product repackaging schemes, consumption-based subscription models, and evolving generative AI offerings — rationalising this as the cost of innovation and AI development. Some SaaS price increases have reached as high as 900 percent, driven by private equity firms focused on short-term profitability.
An organisation that has consolidated its core business functions onto a single vendor's platform has, by definition, made itself highly dependent on that vendor's pricing decisions, product roadmap choices, and acquisition behaviour. The migration cost of leaving a deeply embedded platform is high enough that even significant price increases may be more tolerable than the disruption of switching — which is exactly the leverage position that platform vendors understand and that private equity acquirers of SaaS companies are explicitly building into their post-acquisition pricing strategies.
The answer is not to avoid consolidation — the operational benefits of managing fewer vendors are real and the AI readiness benefits are significant. The answer is to consolidate deliberately, maintaining genuine architectural optionality rather than allowing consolidation to create single-vendor dependencies across functions that would be catastrophic to migrate away from. This requires more sophisticated portfolio strategy than simply reducing vendor count — it requires understanding the switching cost and lock-in profile of each platform before committing to it as a consolidation target.
Building a SaaS Management Programme That Actually Sticks
The organisations that have successfully reduced their SaaS complexity without the disruption that characterises failed consolidation programmes share a set of operational practices that are worth examining specifically, because they are consistently different from the most common approach — which is declaring a consolidation initiative, cutting contracts, and discovering the consequences six months later.
They start with a complete inventory before making any decisions. Establishing your inventory, including authorised and shadow SaaS, using SSO logs, finance and expense data, and API-based usage where possible is the prerequisite for any rationalisation decision. You cannot make good decisions about which tools to consolidate without knowing which tools exist, who uses them, how frequently, and what they connect to. This inventory step consistently reveals tools that no one in IT knew existed and tools that were being renewed automatically without anyone assessing whether they were still needed.
They assign ownership before making cuts. Every tool in the portfolio needs a named business owner who is accountable for evaluating whether it delivers sufficient value to justify its cost and complexity. Ownership makes the evaluation real — when someone's name is attached to a tool's continued existence, the assessment of whether it should stay or go is significantly more rigorous than when the decision sits with a centralised IT team that has limited context about how the tool is actually used.
They build governance that works with how people actually buy software, not against it. The fastest path to shadow IT is a procurement process so slow and bureaucratic that employees route around it to get things done. The organisations that keep their SaaS portfolios manageable over time are the ones that have built lightweight, fast governance — clear domain ownership, a streamlined approval process for new tools, and a regular portfolio review that catches accumulation before it becomes unmanageable. Governance that employees experience as helpful rather than obstructive is governance that gets used. Everything else becomes a workaround waiting to happen.
The SaaS sprawl problem is not going to solve itself. Every month that passes without active management, 7.6 new applications are entering the average enterprise's environment, each one adding a thread to the integration mesh, a line to the security review queue, and a vendor to the renewal calendar. The organisations that built the management infrastructure for this problem before it became a crisis are spending that freed capacity on AI, on product development, and on the capabilities that generate competitive advantage. The ones that have not are spending it on keeping a fragmented, expensive, increasingly fragile technology estate from breaking. The choice between those two futures starts with a decision about whether SaaS management is a governance exercise or a strategic priority. In 2025, there is only one right answer.
