English

SaaS Consolidation: When to Cut a Tool vs. Keep It

The IT lead had been asked to prepare a stack overview for the COO. What she expected to take a few hours took three days. The company had eighty-one active SaaS subscriptions. Fourteen of them had overlapping functionality. Six had fewer than three active users in the prior ninety days. Four were provisioned for employees who'd left more than six months ago.

The total annual spend was $340,000. By the IT lead's estimate, $80,000-120,000 was recoverable through consolidation and decommissioning.

Nobody had been careless. The stack had grown over four years of normal business operation: teams found tools they needed, got them approved, used them for a project, and moved on. Contracts auto-renewed. Usage drifted. No one owned the aggregate picture.

This guide is the consolidation process that turns the IT lead's three-day discovery into a repeatable quarterly exercise. It gives operations leaders the framework to make keep-or-cut decisions without relying on who complains loudest when cuts are proposed. If the underlying issue is that new tools keep getting approved without a structured review, the SaaS buying decision tree is the upstream framework that reduces consolidation requirements over time.

Why Consolidation Recovers More Than You Expect

Most companies underestimate how much consolidation can recover because the spend is distributed across dozens of line items and no single tool looks like the problem. BetterCloud's State of SaaSOps report found that the average mid-market organization wastes 25–40% of its SaaS budget on underutilized or redundant tools — a figure that typically goes undetected until a deliberate audit surfaces it. But the math compounds:

  • A $5,000/year tool with 2 active users costs $2,500 per active user per year.
  • A $20,000/year tool that duplicates functionality already owned in a $30,000/year platform you're keeping costs $20,000 for negative value (it adds complexity, not capability).
  • A tool that auto-renewed while you were mid-consolidation-audit cost you a full year's fees for something you've already decided to cut.

The goal isn't to cut aggressively. It's to cut precisely. Tools that deliver real value at reasonable utilization should stay. Tools that don't meet that bar cost you money, complexity, and IT administration time regardless of how much individual teams like them.

Stage 1: Full Stack Audit

You can't cut what you can't see. The audit stage is about building a complete, accurate picture of the current SaaS stack before any decisions are made.

Finding the Full Stack

Most IT leads think they know the stack. They're usually missing 15-30% of it. Shadow IT (tools purchased on team or personal credit cards, free trials that converted to paid without IT involvement, tools acquired through acquisitions) regularly accounts for a significant portion of actual SaaS spend. Gartner's research on SaaS management and shadow IT estimates that shadow IT accounts for 30–40% of total technology spend in organizations without a formal SaaS management program.

SaaS discovery sources:

Source What It Finds
Finance/AP records Everything billed through accounts payable
Corporate card statements Direct charges by employees
AWS/Azure/GCP marketplace Cloud-billed SaaS purchased through cloud platforms
SSO/IdP logs Tools connected to Okta, Azure AD, Google Workspace
Browser extension audit SaaS tools installed via browser extensions
Email domain analysis SaaS trial signups using company email addresses
Employee survey Direct ask: "what tools do you use that aren't on the approved list?"

No single source gives you the complete picture. Run at least the first four in parallel.

Building the Audit Spreadsheet

For each tool identified, capture:

Field Why It Matters
Tool name and category Enables overlap mapping
Annual cost Prioritizes what's worth auditing deeply
Seat count (contracted vs. provisioned vs. active) Surfaces over-provisioning
Contract renewal date Prevents accidental auto-renewal during audit
Contract term and notice requirements Determines exit timeline
Owner (person responsible) Assigns accountability for keep/cut decision
Last active use (date) Quick signal for abandoned tools
Primary use case Enables overlap mapping
Integrations in use Critical for decommission planning

SaaS Stack Audit Template:

| Tool | Category | Annual Cost | Seats: Contract/Active | Renewal Date | Notice Req. | Owner | Last Use | Primary Use Case | Integrations |
|------|----------|-------------|------------------------|-------------|-------------|-------|----------|------------------|--------------|

This spreadsheet is the working document for everything that follows. Keep it current. Update it whenever a new tool is approved or a tool is decommissioned.

Stage 2: Overlap Mapping

Once you have the full stack, map which tools serve overlapping functions. This is where the consolidation opportunity becomes visible.

Category Grouping

Group tools by function, not by vendor category:

  • Communication: messaging, email, video conferencing
  • Project and task management: project tracking, to-do lists, work management
  • Document and knowledge management: wikis, docs, file storage
  • CRM and sales: contact management, pipeline tracking, sales engagement
  • HR and people management: HRIS, performance, recruiting, onboarding
  • Analytics and BI: dashboards, reporting, data visualization
  • Customer support: ticketing, live chat, help desk
  • Finance and accounting: expense management, invoicing, procurement

In each category, flag every tool the company is paying for. A category with three tools almost always has consolidation potential.

The Overlap Heat Map

Build a simple heat map for each category:

Category: Project Management Tool A Tool B Tool C
Task tracking X X X
Project timelines X X
Resource allocation X
Time tracking X X
Client-facing projects X
Reporting X X

If Tool A and Tool B have 70%+ feature overlap, that's a consolidation candidate. If Tool A has a feature that Tool B doesn't, that's a migration dependency to plan for.

Stage 3: Utilization Scoring

Overlap tells you where consolidation is possible. Utilization scoring tells you which tool to keep.

The Five-Criteria Utilization Matrix

Score each tool in an overlapping set on five criteria, 1-5:

Criteria Definition
Active user rate % of provisioned users who logged in within the last 30 days
Workflow criticality Impact on team output if the tool disappeared tomorrow
Integration depth Number and importance of integrations currently in use
Replacement difficulty How hard would it be to migrate functionality to another tool?
Cost efficiency Value delivered per dollar of annual cost

Scoring guide:

Score Active User Rate Workflow Criticality Integration Depth Replacement Difficulty Cost Efficiency
5 >80% Business-critical 5+ integrations Migration >90 days High value, reasonable cost
4 60-80% Important 3-5 integrations Migration 30-90 days Good value
3 40-60% Useful 1-2 integrations Migration 2-4 weeks Fair value
2 20-40% Occasional use API access only Migration <2 weeks Poor value
1 <20% Rarely used No integrations Easy to leave Very poor value

Total score determines the disposition:

  • 18-25: Keep. This tool is delivering real value and is integrated enough to be costly to replace.
  • 11-17: Evaluate. This tool is delivering some value but there may be a consolidation path worth scoping.
  • 5-10: Decommission candidate. Low utilization, low integration, low workflow criticality. The cost of keeping it outweighs the effort of replacing it.

Common Scoring Mistakes

Scoring on features instead of utilization. A tool with impressive capabilities that nobody uses scores the same as a tool with no capabilities that nobody uses. Active use rate is the first filter.

Letting the loudest advocate determine the score. The person who championed the tool purchase will fight to keep it. Get utilization data from the tool itself (login counts, active users, feature usage logs) rather than relying on the owner's self-assessment. And when evaluating what a kept tool actually costs, TCO modeling for SaaS gives you the five-category framework to model the true cost of tools you're deciding to retain — not just the license fee.

Ignoring workflow dependency that isn't in the integrations count. A tool might have no API integrations but be deeply embedded in a workflow because people manually export from it into a spreadsheet that feeds another process. Check for informal dependencies as well as formal ones.

Stage 4: Decommission Sequencing with Migration Plan

With the scoring complete, you have a list of decommission candidates. The sequencing is as important as the decision. Cutting in the wrong order or without migration planning creates the disruption that kills the political will to finish the project.

Decommission Sequencing Principles

  1. Start with zero-impact tools first. Tools with scores of 5-7 (very low utilization, no integrations, no active users) are fast wins that recover budget and build momentum. Decommission these first.

  2. Group overlapping pairs for migration. For a category where two tools overlap and you're consolidating to one, plan the migration together. Users need a clear move path, not a gap.

  3. Respect contract renewal dates. There's no point planning to decommission a tool in month three if the contract auto-renews in month two. Map renewal dates against the decommission plan. Calendar renewal notice deadlines. You need to give notice before the window closes, not when you're ready. The SaaS contract red flags guide explains how auto-renewal window lengths and notice requirements vary across contracts.

  4. Run parallel for critical tools. When decommissioning a high-utilization tool, run both the old and new tool in parallel for the final two to four weeks of the migration. Don't hard-cut before users are migrated.

20-Step Decommission Checklist

Pre-decommission (Weeks 1-2):

  • Decision made and communicated to tool owner
  • Contract renewal date confirmed and calendared
  • Notice of non-renewal sent if required
  • All users of the tool identified
  • Active workflows depending on the tool documented
  • Integrations dependent on the tool identified
  • Data export requirements scoped (format, volume, timeline)
  • Migration target confirmed (what tool replaces this use case?)

Migration (Weeks 3-6):

  • Migration timeline communicated to users
  • Data exported in required formats
  • Data imported into replacement tool (or archived if no replacement)
  • Integrations rebuilt or deactivated in the decommissioned tool
  • Users provisioned in replacement tool
  • Training completed for users on replacement tool
  • Parallel run period set (old tool still accessible, new tool active)

Decommission (Final week):

  • Remaining data exported and archived
  • All users confirmed migrated
  • Cancellation submitted with confirmation received
  • IT access/SSO connection deactivated
  • Cost confirmed removed from billing
  • Stack audit spreadsheet updated

Measuring the Consolidation

Track these at 6 and 12 months post-consolidation:

Metric Target
SaaS spend reduction 20-35% of pre-consolidation spend
Tool count reduction Depends on starting count; target 25-40% reduction
IT administration time Reduction in support tickets related to tool issues
End-user productivity impact Self-reported satisfaction survey + actual output metrics
Shadow IT incidents Reduction in unapproved tools discovered

One metric to watch carefully: end-user productivity in the first 60 days after consolidation. McKinsey's research on organizational change management found that technology consolidation projects that include structured user communication and migration support achieve full productivity recovery 40–50% faster than those that treat consolidation as purely a cost exercise. If you cut tools people were genuinely using and didn't provide adequate migration support, you'll see productivity impacts that undermine the financial case. The consolidation savings should show up in the budget; the productivity cost shouldn't show up in the team.

Learn More