Most companies run more software than anyone can list from memory. According to Zylo’s 2025 SaaS Management Index, large enterprises use 660 SaaS applications on average, and smaller companies use 152. Organizations waste an average of USD 21M a year on SaaS licenses nobody uses, and that figure grew 14.2% in a year.
SaaS is only part of the picture. On-premise systems, custom builds and integrations between them add support costs, security exposure and technical debt. Application rationalization is how IT teams cut that portfolio down to what the business actually needs. This guide covers the process step by step, a scoring model you can reuse and how to turn scores into decisions.
What Application Rationalization Means
Application rationalization is a structured review of every application in the portfolio. For each one, the team decides whether to keep it, invest in it, move it to a new platform or retire it. The goal is a smaller portfolio where every application has a clear owner, a clear purpose and a cost the business accepts.
It is often confused with application portfolio management (APM). APM is the ongoing practice of tracking applications, their costs and their health. Rationalization is the decision cycle that runs on top of that data. Without APM, every rationalization starts from a blank spreadsheet. Without rationalization, APM produces reports that nobody acts on.
The scope also varies. SaaS rationalization focuses on subscriptions and licenses, which is where vendors like Zylo and Torii start. Full-portfolio rationalization also covers on-premise software, custom applications and integrations. That is where most of the technical debt and the biggest savings sit.
When to Run Application Rationalization
The best time is before a big change, not after it. Typical triggers:
- Cloud migration. Moving an application you should have retired wastes the migration budget. Rationalize first, then migrate what is left. If vendor lock-in is part of the plan, the EU Data Act cloud switching rules are worth reading too.
- Mergers and acquisitions. Two companies usually bring two CRMs, two HR systems and two of everything else.
- Budget pressure. Retired applications are one of the few IT savings that do not reduce what the business can do.
- End of vendor support. An application losing support forces a decision anyway. Rationalization makes it a planned one.
- A growing technical debt register. If technical debt keeps piling up in systems nobody wants to own, some of those systems may not need to exist.
The Application Rationalization Process in 6 Steps
The process below follows the six-step loop from the US federal CIO Council’s application rationalization playbook, adapted for companies of any size.
Step 1: Set scope and governance
Decide which part of the portfolio you review first and who makes the final calls. A working group should include IT, finance, procurement, security and the business units that use the applications. The CIO Council playbook also recommends starting with less critical support applications. They make a safer pilot before you move on to core systems.
Step 2: Build the inventory
List every application in scope, with its owner, users, vendor, contract dates, integrations and hosting. Pull data from existing sources first: software asset management tools, SSO logs, finance records and procurement contracts. Then fill the gaps with a short questionnaire to application owners.
Shadow IT is the usual blind spot. Zylo found that lines of business control 70% of SaaS spend, while IT controls 26.1%. Expense reports and SSO data show applications that never went through IT.
Step 3: Assess business value and technical fit
Rate each application on two dimensions:
- Business value: which processes depend on it, how many people use it, what happens if it stops. This is where business-IT alignment becomes practical: application owners in the business have to confirm the value, not just IT.
- Technical fit: platform currency, vendor support, security posture, integration quality, and the known technical debt in the system.
At this step, also map dependencies and overlaps. Two tools that do the same job are the fastest savings in most portfolios.
Step 4: Calculate total cost of ownership
License fees are only the visible part. Total cost of ownership includes support contracts, infrastructure, integrations, internal staff time, training and security tooling. The CIO Council playbook warns that indirect costs such as training and certification are often missed. Without them, the cheapest-looking application is not always the cheapest one.
Step 5: Score and decide
Combine value, fit, cost and overlap into one score per application, then assign a decision. The scoring model and the TIME framework below show how.
Step 6: Retire, consolidate and migrate
Decisions only save money once they are carried out. For each retirement, plan the data: what to migrate, what to archive for compliance and what to delete. Notify users early and set a firm switch-off date.
Budget for the migration bubble. While old and new systems run in parallel, costs go up before they go down. Applications marked for migration move into a modernization plan. Our legacy system modernization guide covers the options, from rehosting to full replacement.
An Application Rationalization Scoring Model with an Example
A scoring model keeps decisions consistent and makes them easy to defend. Rate business value and technical fit from 1 to 5, record annual TCO and note any overlap. A score of 3 or higher counts as high.
| Application | Business value | Technical fit | Annual TCO | Overlap | Decision |
|---|---|---|---|---|---|
| Core ERP on a current version | 5 | 4 | USD 1.2M | None | Invest |
| On-premise CRM on an unsupported database | 5 | 2 | USD 380,000 | None | Migrate |
| Second project management tool used by one team | 2 | 4 | USD 45,000 | Duplicates the main PM tool | Tolerate, consolidate at renewal |
| Old reporting tool replaced by the BI platform | 1 | 1 | USD 90,000 | Fully covered by BI | Eliminate |
The example shows why cost alone is a poor guide. The ERP is the most expensive application on the list and still the one to invest in. The reporting tool is cheap, but it adds cost with no value, so it goes first.
You can use the same table as an application rationalization template. Add columns for owner, contract end date and number of users, and it becomes the working document for the whole review.
The Gartner TIME Model
The TIME model from Gartner is the most common way to turn scores into decisions. It places each application on two axes, technical fit and functional (business) fit, and gives four outcomes:
| Decision | Business value | Technical fit | What to do |
|---|---|---|---|
| Tolerate | Low | High | Keep as is with minimal spend, review at contract renewal |
| Invest | High | High | Extend, integrate and keep current |
| Migrate | High | Low | Move to a new platform or replace while keeping the function |
| Eliminate | Low | Low | Retire, archive the data, cancel the contract |
TIME works best as the last step, not the first. Without a reliable inventory and honest scores, the quadrants only reflect opinions. Some teams use other labels, such as the CIO Council’s review, reward, refresh and remove, but the logic is the same.
Common Mistakes
- Treating it as a one-off project. New applications appear every month. Without an onboarding rule for new software, the portfolio grows back within a year.
- No owner per application. If nobody owns an application, nobody can confirm its value, and nobody signs off on retiring it.
- Cutting without a data plan. Retired systems often hold records that legal or finance need for years. Archive first, switch off second.
- Ignoring the users. Removing a tool people rely on without a working replacement pushes them back to shadow IT.
- Counting only license savings. Infrastructure, support and staff time released by a retirement often matter more than the license fee.
How to Measure the Results
Track a short set of numbers before the review and every quarter after it:
- Number of applications in the portfolio, and the number retired
- Annual license, support and infrastructure costs released
- Number of overlapping capabilities (for example, how many tools do project management)
- Share of applications with a named owner and current vendor support
- Known technical debt items removed with retired systems
The last metric links rationalization to the rest of the IT roadmap. Every retired system takes its debt and its security exposure with it.
FAQ
What is the difference between application rationalization and application portfolio management?
Application portfolio management is the continuous practice of tracking applications, their costs and their condition. Application rationalization is the review that uses that data to decide what to keep, change or retire. APM keeps the data current; rationalization acts on it.
What is the Gartner TIME model?
It is a framework that sorts applications by technical fit and business fit into four decisions: Tolerate, Invest, Migrate and Eliminate. It helps teams turn scores into consistent actions across the portfolio.
How long does application rationalization take?
A first pass on a limited scope, such as one business unit or a set of support applications, usually takes a few months. A full portfolio review in a large company takes longer, mostly because building a reliable inventory is slow. Retirements themselves follow contract end dates.
How often should you rationalize applications?
Keep the inventory continuous and run a decision cycle at least once a year. Align reviews with contract renewals, so each renewal becomes a natural point to keep, replace or cancel.
Who should own application rationalization?
IT usually runs the process, but decisions need the business. Application owners confirm value, finance confirms cost, security confirms risk, and IT leadership signs off the final portfolio plan.
How do you decide which applications to retire?
Start with applications that score low on both business value and technical fit, and with tools that duplicate another application. Check dependencies and data retention needs before you set a switch-off date.
