SaaS Buying Framework for Operators
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
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.
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.
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.
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
- The SaaS Sprawl Problem: Signs You Have It and How to Fix It — the governance changes that prevent needing a consolidation again in 18 months
- TCO Modeling for SaaS: Beyond the Sticker Price — how to model the true cost of tools you're deciding to keep
- The SaaS Buying Decision Tree: When to Buy, Build, or Bolt On — the upfront decision framework that reduces future consolidation requirements
- Switching SaaS Vendors: The Hidden Cost of Migration — the migration cost model that informs decommission sequencing
- Procurement vs operations ownership — who should own the consolidation process and how to run it across teams
- Data migration planning — how to plan the migration component of a decommission for high-risk tools

Head of Enterprise Solutions
On this page
- Why Consolidation Recovers More Than You Expect
- Stage 1: Full Stack Audit
- Finding the Full Stack
- Building the Audit Spreadsheet
- Stage 2: Overlap Mapping
- Category Grouping
- The Overlap Heat Map
- Stage 3: Utilization Scoring
- The Five-Criteria Utilization Matrix
- Common Scoring Mistakes
- Stage 4: Decommission Sequencing with Migration Plan
- Decommission Sequencing Principles
- 20-Step Decommission Checklist
- Measuring the Consolidation
- Learn More