What Rationalisation Is — and Isn't
Software licence rationalisation is the structured review of the entire software portfolio to ensure every application has a clear purpose, is actively used, and delivers real business value — removing waste, duplication, and risk in the process. It is distinct from reclamation: where licence reclamation recovers unused seats of a tool you keep, rationalisation decides which tools you keep at all. It is the deepest layer of the waste work described in our enterprise IT cost optimization pillar.
The prize is large and well documented. Organisations typically reduce IT costs by 15–30% through effective portfolio rationalisation, and global averages suggest 20–30% of the IT budget can be saved by retiring redundant applications — while simultaneously cutting security and compliance overhead. A typical engagement runs 6–12 months and retires, consolidates, or renegotiates 15–30% of the estate within 18 months.
Step 1: Inventory and Normalise
Everything depends on a complete, normalised inventory, and this is the step most programmes underinvest in. You need every application — including the shadow purchases mapped in our guide to shadow IT licensing risks — with its contract, cost, owner, and crucially its actual usage rather than its installation count. Normalisation matters: the same product appears under a dozen version strings and SKUs, and until those are grouped, the data lies. AI-powered SAM tools now automate much of this discovery and usage tracking, which is why most 2026 programmes instrument usage first and decide later. The data foundation here is the same one built for IT spend analytics, and the business case for the capability is quantified in our software asset management ROI calculator.
Step 2: Score With the TIME Model
With clean data, score each application using the Gartner TIME model, which sorts every application on two axes — business value and technical fit — into one of four actions. This gives a defensible, consistent basis for decisions, so the portfolio is shaped by scoring rather than by whoever argues hardest for their favourite tool.
| TIME Category | Value / Fit | Action |
|---|---|---|
| Tolerate | Useful function, weaker value | Keep for now, do not invest |
| Invest | High value and high fit | Fund and standardise on it |
| Migrate | Valuable but weak technology | Move to a better platform |
| Eliminate | Low value, poor fit | Retire and reclaim spend |
The TIME model turns a political argument into a scoring exercise. "We can't kill that, my team loves it" becomes "this scores low on value and fit" — and a low score is far harder to argue with than a preference.
The scoring is only as good as the criteria behind it, so define them before you score, not after. Business value should be evidenced — number of active users, revenue or process dependency, regulatory necessity — rather than asserted by the application owner. Technical fit should capture supportability, integration burden, security posture, and roadmap viability. The two-axis scoring then places each application on the grid mechanically, which is what removes the politics: the conversation shifts from whether a tool should survive to whether the inputs to its score are accurate, a far more productive argument. Score the most expensive and most critical vendors first, where the analysis pays back fastest, then work down the portfolio.
Step 3: Map Functional Overlap
Scoring evaluates each application alone; overlap mapping reveals where several do the same job. Functional redundancy — three project tools, four diagramming apps, overlapping security agents — is where consolidation savings concentrate, because removing a duplicate costs no capability at all. Plot every application against the capability it delivers, and the clusters of redundancy become obvious. This is the bridge from rationalisation into contract consolidation: rationalisation decides which overlapping tools to drop, and consolidation negotiates the surviving spend onto better terms.
Step 4: Execute
Execution turns the analysis into recovered budget through three actions. Retire the Eliminate-category and redundant applications, decommissioning cleanly and reclaiming the spend. Consolidate overlapping tools onto the Invest-category survivor, migrating users and data. Renegotiate the contracts for what remains, using the rationalised, accurate position as the basis — a documented over-deployment or a reduced footprint is powerful leverage at the table. Where a surviving application is simply over-provisioned rather than redundant, pair retirement with the tier and edition discipline in our guide to right-sizing enterprise software. Sequence by capability risk: retire the obvious waste first, consolidate second, and touch business-critical systems only with a migration plan in hand.
Sustaining the Programme
A one-off rationalisation decays as new tools creep back in, so the final step is governance: an intake process that scores new requests against the existing portfolio before purchase, and an annual re-scoring of the estate. Built into the procurement process, rationalisation becomes a standing control rather than a periodic project. For help running a rationalisation programme — from instrumenting usage to renegotiating the surviving contracts — request a confidential briefing, or download our SaaS optimisation guide to start the inventory in-house.