By 2017 the typical mid-sized company was running five tools that did roughly the same job, and nobody had decided to do that. Collaboration tool sprawl was not a procurement failure; it was the predictable output of a purchasing model in which any manager with a corporate card could adopt software for a team in an afternoon. The pattern was consistent enough to be recited. Email everywhere. A chat platform adopted bottom-up by engineering, another by marketing because it came bundled with something else. Two or three file storage services, one official and the others accumulated through client requirements. A project tracker per department, chosen by whoever set the department up. A video conferencing tool per major client, because each client insisted on theirs. A wiki that stopped being maintained in 2014 and a newer documentation tool that will stop being maintained next year. Plus the shadow layer of personal messaging apps carrying a substantial share of actual business communication. The usual response was a rationalisation programme aimed at consolidating onto one platform. Most of those programmes underdelivered, and the reason is worth understanding before starting another one.
What sprawl actually costs
The licence duplication is the visible cost and the smallest one. The real costs are structural. Findability collapses. When a decision could be in any of four systems, the practical answer is that institutional knowledge does not exist. People re-ask, re-decide and re-do work. This is the largest cost and the hardest to quantify, which is why it rarely appears in business cases. The security surface multiplies. Each platform is an authentication boundary, a set of external sharing settings, an integration catalogue, a data location and an offboarding step. Organisations with twelve collaboration tools do not have twelve times the risk; they have an unbounded risk, because nobody can enumerate the tools, let alone the external guests inside them. Compliance becomes unanswerable. A data subject request, a litigation hold, a regulator asking where personal data resides — each requires knowing which systems hold what. Sprawl makes that question unanswerable in practice, and the answer given is usually wrong rather than absent. Onboarding and offboarding degrade. New joiners learn a different tool per team. Leavers retain access to whatever was not centrally provisioned, which by definition is the sprawl. Context switching taxes everyone. Five places to check is not five times the cost of one; it is a persistent low-grade attention drain plus the recurring failure of missing something that was posted somewhere you were not looking.
Why consolidation programmes fail
Three reasons, and they recur. The first is that the alternative was chosen for a reason. Teams did not adopt a second project tracker out of mischief; the sanctioned one did not do what they needed, or was slower, or required a licence they could not get approved. Consolidation that does not address the original need produces compliance in form and migration in substance — the team uses the mandated tool for the record and the old one for the work. The second is that migration cost scales with history, and organisations consistently plan for the tool and not the content. Moving a team's messages is easy; moving four years of documents with their sharing permissions, links and references is a project. Leaving the old system running in read-only mode is the pragmatic answer, and read-only systems have a way of becoming writable again. The third is that consolidation is treated as an IT exercise when it is an operating-model change. Which tool holds the record of a decision, where a project's status lives, what counts as documentation — these are not configuration questions. If they are not answered, the new platform absorbs the same sprawl inside itself, as a thousand channels and an unnavigable document tree.
A rationalisation approach that works
Start with discovery rather than policy. Pull the actual inventory from expense records, single sign-on logs, network traffic and a short survey — and expect the number to be two or three times the official one. Then categorise by job rather than by vendor: real-time conversation, durable documentation, file storage, work tracking, meetings, and the record of decisions. The objective is one primary tool per job, not one tool overall. Organisations that pursue a single platform for everything usually end up with something mediocre at four jobs and disliked for all of them. For each duplicate, ask why the alternative exists before removing it, and fix the gap or accept the exception explicitly. Exceptions with owners and review dates are governance; undocumented exceptions are sprawl with extra steps. Sequence by risk and cost: retire the unused first, since dormant systems holding data are pure exposure. Then consolidate where the gap is small. Leave the genuinely contested categories until the programme has credibility. Finally, close the tap. Sprawl regenerates within eighteen months unless adoption of new collaboration software requires a decision with a named approver, and unless someone is accountable for the inventory on an ongoing basis.
Practical Guidance for SaaS Rationalization Review
- Discover before you decide, using expense data, SSO logs and network traffic. The real inventory is usually two to three times the official one.
- Aim for one primary tool per job, not one tool for everything. Single-platform strategies produce mediocrity across four categories at once.
- Ask why each duplicate exists before retiring it. Unaddressed gaps produce shadow reversion, which is worse than the original sprawl.
- Retire dormant systems first. Unused platforms still hold data, external guests and credentials, and removing them is pure risk reduction.
- Plan content migration separately from tool migration. Message history is easy; documents with permissions, links and references are the project.
- Decide where the record of a decision lives. Without that answer, the consolidated platform recreates the sprawl internally.
- Require named approval for new collaboration software and keep the inventory owned. Sprawl regenerates in about eighteen months otherwise.
- Count the security and compliance saving, not just licences. Fewer authentication boundaries and fewer places personal data can hide is most of the value.
The Regional Angle
Tool sprawl in the Gulf has causes that are structural rather than cultural, and they change what rationalisation should target. Group structure is the first. Regional businesses are frequently diversified family or state-linked groups — a contracting arm, a retail chain, a logistics operation, a healthcare division, a property portfolio — assembled by acquisition and run with substantial divisional autonomy. Each arrived with its own systems and its own integrator relationship. What looks like sprawl from the centre is often the accurate reflection of a holding structure in which the divisions genuinely do operate independently. Consolidating collaboration across such a group is a governance decision about how integrated the group intends to be, and attempting it as an IT rationalisation without that decision fails predictably. WhatsApp is the second and largest, and any regional rationalisation that ignores it is measuring the wrong thing. A meaningful share of business communication — client conversations, supplier coordination, internal approvals, field operations — runs on personal messaging outside every governed platform. An organisation can consolidate from eight sanctioned tools to three and leave the majority of its actual communication untouched. The realistic goal is not elimination but boundary setting: which categories of communication must occur in a governed system, with payment instructions and contractual approvals as the non-negotiable minimum, and a governed path that is genuinely usable on a phone for the rest. The frontline majority is the third. In retail, logistics, hospitality, construction and facilities, the bulk of the workforce is mobile and multilingual — Arabic, English, Hindi, Urdu, Malayalam, Tagalog, Bengali, Nepali — and often without a corporate email address. Knowledge-worker collaboration platforms do not serve them, which is why frontline-specific tools proliferate alongside the office stack. That is not sprawl to be eliminated; it is a second operating model that needs its own primary tool and its own governance. Two further specifics. The integrator-led estate means many platforms were introduced by implementation partners as part of larger programmes, and retiring them touches commercial relationships rather than just licences — check what is bundled into managed service contracts before assuming a tool can be dropped. And data residency now makes the inventory a compliance artefact: with Saudi PDPL, UAE sector rules and the DIFC and ADGM regimes in force, each additional platform is another hosting location and another transfer to justify. In several regional engagements the residency argument has carried rationalisation further than the cost argument ever did, because it converts sprawl from an inefficiency into a regulatory exposure with a named owner.
The objection worth taking seriously
The strongest criticism is that consolidation programmes destroy real value and count only the savings. Teams choose tools that fit their work. A design team on a specialist collaboration platform, an engineering group on a tracker built for their workflow, a sales organisation on something integrated with the CRM — these are not indulgences, and moving them onto a general-purpose platform imposes a productivity cost that is paid daily by the people doing the work while the saving accrues centrally and visibly. Rationalisation business cases almost never include that cost, which makes them systematically biased toward consolidation. The honest version prices the disruption and the ongoing fit penalty, and frequently concludes that the specialist tool should stay and the three redundant general ones should go. There is also a governance-versus-agility argument with genuine force. The reason sprawl happened is that teams could solve their own problems quickly, and that capability has real value — particularly in a market where central IT is often small and integrator-dependent. Locking procurement down entirely trades one set of costs for another: slower adaptation, more shadow IT, and a central function that becomes a bottleneck people route around. The defensible middle is a light approval path with a fast answer, a published list of sanctioned tools per job, and central attention reserved for the things that actually matter — where data lives, who can access it, and whether it can be offboarded. And a point about proportionality. For a company of fifty people, twelve tools is a genuine problem and a week of work to fix. For a diversified group of eight thousand across five divisions, a single collaboration platform may be the wrong target entirely; the achievable win is a common identity layer, consistent external sharing controls, a maintained inventory, and one agreed place where decisions are recorded. That is less satisfying than a consolidation headline and it is usually where the value actually is.
Common Questions
How many collaboration tools is too many?
The count matters less than whether each job has a primary tool and whether someone owns the inventory. Duplicates within a category cause the damage; specialist tools serving genuinely different work usually do not.
What is the biggest hidden cost of sprawl?
Findability. When a decision could be in any of several systems, institutional knowledge effectively ceases to exist and work gets repeated. It is larger than licence duplication and almost never quantified.
Should consolidation aim at a single platform?
Rarely. One primary tool per job — conversation, documentation, storage, work tracking, meetings — outperforms one tool for everything, which tends to be adequate at several things and resented for all of them.
How does AI change the sprawl calculation?
It raises the value of consolidation sharply, for a reason that did not exist in 2017. AI assistants answer from what they can reach, so an organisation whose knowledge is scattered across eight systems gets confidently incomplete answers — and an incomplete answer delivered fluently is more dangerous than no answer, because nobody checks. Consolidation, or at least connecting the primary systems to a common retrieval layer, is now the precondition for AI being useful rather than a tidiness exercise. Three cautions follow. Each AI feature added to each platform is a new processor and a new data flow, so the sprawl problem reproduces itself at the AI layer faster than at the application layer — inventory the AI features, not just the applications. Permission-aware retrieval must be verified per platform rather than assumed, because a summary can carry content across a boundary the reader could not cross directly. And unmanaged archives become newly consequential: a dormant system that was harmless as a forgotten folder becomes a source of stale decisions surfaced with confidence once something indexes it.
SaaS Rationalization Review — one primary tool per job, ask why each duplicate exists, and close the tap or it all comes back in eighteen months.