SaaS rationalisation, done properly: the audit methodology that beats tool-count arguments
Every IT and engineering leadership team we speak to this year is under pressure to reduce the number of SaaS subscriptions. The pressure comes from two directions: finance wants the spend line reduced; security wants the attack-surface reduced. Neither pressure answers how to decide what goes. “We have too many tools” is not analysis. A rationalisation effort that starts from tool counts rather than capability overlaps produces either a superficial saving or a costly mistake.
This is the audit methodology we recommend for teams in the 50–5,000 person range. It is boring. It works. It is also shorter than most teams expect, once the data is gathered well.
Step 1 — Build the true inventory, not the purchased inventory
The finance system knows what is paid for. It does not know what is used. A working inventory has four sources:
- SSO / IdP logs — every app behind Okta, Entra, Google Workspace. These are the sanctioned ones.
- Corporate card and expense feeds — the shadow subscriptions on individual cards.
- Network egress logs — domains being resolved, filtered to SaaS-looking domains. This catches tools with no SSO and no central billing, including personal-tier accounts used for work.
- Endpoint management data — installed browser extensions and desktop agents.
We do not recommend publishing a single “we have N SaaS apps” number after this step. The number depends on classification choices (does a Slack-connected micro-SaaS count?) and will be challenged. Publish the overlapping-categories count instead.
Step 2 — Duplicate capability mapping
The point of the audit is finding capabilities bought more than once. Build a capability grid, not a product list:
| Capability | Products providing it | Primary owner | Notes |
|---|---|---|---|
| Video meetings | A, B, C | A | B is a remnant of an acquisition |
| Async video | C, D | D | C’s async is barely used |
| Whiteboard | D, E, F | E | D bundles it; usage is 4% |
| Document signing | G, H | G | H is one team’s shadow card |
The “primary owner” column is not a political label; it is the observation of where work actually happens. Identifying the default tool for a capability is what makes the cut decisions defensible later.
A common mistake: treating bundled features as duplicates. If product X is under contract and its video capability is mediocre, the fact that video is “already bought” does not make it a candidate to replace a dedicated video tool. Capability quality matters more than capability presence.
Step 3 — Integration inventory
For each candidate to be cut, enumerate what depends on it. This is where SaaS rationalisation projects die: a tool that looks cheap to remove is wired into fifteen workflows. Inventory:
- API integrations (incoming and outgoing)
- Webhooks and event subscriptions
- Zapier / Make / n8n / Workato flows
- Scheduled exports feeding data warehouses
- Embedded links in docs and wikis
Tools with no live integrations are easy cuts. Tools with deep dependency webs are replacement projects, not cancellations — the rationalisation benefit arrives only after migration completes. If your timeline is quarterly, place these in a later wave.
Step 4 — Licence utilisation measurement
Utilisation determines whether the saving is a cancellation or a downgrade. For each product:
- Active users in the last 90 days, as a fraction of paid seats.
- Feature breadth per active user: does the average user touch 2% of the product, or 40%?
- Tier fit: are you paying Enterprise for features nobody enables?
SaaS vendors count “active” generously. Apply a consistent house definition (a real action, not a login) across products, or numbers will not be comparable.
Step 5 — Decide; document the counterfactual
For each tool, the decision is one of: retain, downgrade, consolidate (migrate to another tool already retained), or cancel.
The discipline is writing down, for retain decisions, why this tool survives when its capabilities overlap others. If the grid says “we keep B because team X is habituated to it,” that is still a legitimate reason — but it should be visible. Habits are a cost of switching, and ignoring them produces failed migrations.
For consolidation decisions, write down the migration owner and the definition of done before cancel notices go out. A cancelled contract with a half-finished migration is the most expensive outcome in this exercise.
What not to rationalise
Three things routinely go wrong:
- Don’t cut the security tooling to hit the count. SIEM, EDR, secrets management, and email security overlap in capability grids, and they are legitimately overlapping. Defence-in-depth is a reason, not redundance.
- Don’t rationalise engineering tooling top-down. Developer tools have workflow affinity that finance does not model. Forcing a team off its CI or observability tool produces a drop in delivery speed that dwarfs the licence saving.
- Don’t chase the tail. A £10/month subscription with zero usage is a cancellation email, not a workstream.
The output that matters
The deliverable of the audit is not a list of cancellations. It is a defensible capability map, a dependency graph, and a migration plan. Vendors change pricing, get acquired, and ship new features; the map is the asset that informs the next round, whether that is in 12 months or after an acquisition.
The bottom line
Run the inventory from logs, not from finance records. Map capability overlaps, not product counts. Inventory dependencies before announcing cancellations. Document retain decisions as rigorously as cuts. Teams that follow this sequence get a real stack reduction; teams that skip it get a press release about “consolidation” and the same stack a year later.