Consider an illustrative renewal review: 14 SaaS subscriptions, a clear bill for each, but no reliable account of what would stop working if one were cancelled. The count is hypothetical. The decision is whether you know enough about the work behind each subscription to change it.
For a COO or operations director, SaaS portfolio rationalization should begin with that test. Establish what each application supports, who depends on it and who owns the consequences of changing it. Then decide what to retain, consolidate or retire, without making a smaller portfolio the overriding objective.
Investigate fragmentation, not the tool count
Ask responsible managers to trace critical work through the portfolio: where records originate, which system holds the authoritative version, where approvals happen and where someone carries information between applications. Include spreadsheets and manual handoffs, even though they do not appear on the subscription ledger.
Use unclear boundaries to direct the investigation. Where tools serve distinct requirements, retention may be justified. Where work is repeated, test whether consolidation would remove that repetition or move it elsewhere. Require every proposed cancellation to identify the work that will cease, move or remain, and who will accept the resulting workflow.
The process below is a recommended governance framework, not a tested savings formula. None of the supporting evidence is specific to 50–500-person firms, and it establishes neither an ideal tool count nor a financial return or disruption-free migration.
Build an inventory around work, data and ownership
Start with the subscription ledger, then have business and technical owners complete an operational record for each application. Make unknowns explicit. An unexplained integration or missing owner is an issue to resolve, not evidence that a tool is dispensable.
- Work and users: business process, required capabilities, user groups and accountable business owner.
- Data and controls: records held, authoritative data, approvals, access controls and retention obligations.
- Dependencies: incoming and outgoing integrations, spreadsheets, manual transfers and the owners of connected workflows.
- Technical ownership and criticality: technical owner, acceptable interruption and responsibility for recovery.
- Commercial commitments: cost owner, recurring charges, allocated licences, renewal dates, notice periods and exit obligations.
Keep current subscription costs separate from the estimated cost of change. Record migration, integration work, training and temporary parallel operation where applicable, with assumptions attached to each estimate. Do not count a removed subscription fee as net savings before accounting for these costs and any changes to the retained service.
Separate duplication from necessary specialization
Compare tools against required work, not feature labels. Ask process owners to specify the workflows, approval rules, data access, reporting and system connections that must remain. Test functional fit against those requirements and technical fit against integration, data-handling and support needs. Require the proposed retained application to meet both without unacceptable manual work or control gaps.
AlixPartners’ TIME framework identifies applications with low functional and technical fit as prime targets for immediate decommissioning. This is consultancy guidance, not evidence that immediate removal is safe. Use weak fit to nominate candidates, then require dependency, data-retention and continuity reviews before approving retirement.
Document the functional, technical or control reason.
Test the retained tool against required work and dependencies.
Resolve work, data and continuity obligations before approval.
Assign unanswered questions and a review date.
Recommended decision criteria, not a validated scoring model.
Retain justified specialization, assess verified overlap and hold decisions where dependencies remain unclear.Give retention a reason, an owner and a review date. For consolidation, name the destination for each required capability and the person who will verify it. Similar functionality should open the assessment, not settle it.
Use observed usage to challenge licence assumptions
AlixPartners recommends robust endpoint monitoring to identify underused software licences and eliminate unnecessary ones while preserving productivity. Treat this as experience-based guidance, not measured proof of savings or a guarantee that removal will leave productivity unchanged.
Compare allocated licences with observed activity over a period covering the relevant business cycle. Record what the measurement captures and what it misses. Before reducing access, ask the process owner whether apparently inactive licences support periodic work, critical exceptions or dependencies outside the usage measure.
Keep seat reductions separate from application retirement. Investigate unused licences without committing to replace the tool; do not exempt an actively used application from a fit review. Usage should inform the decision alongside required work, controls, cost and continuity.
Set decision rights across operations, IT and finance
In SAP LeanIX’s 2025 online survey of 225 enterprise-architecture managers from its global customer portfolio, 61% cited lack of collaboration between IT and business stakeholders as their biggest challenge, while 82% described application-portfolio decision-making as time-consuming and difficult. These self-reported findings come from a provider-affiliated customer cohort. They are not estimates for 50–500-person firms.
Practitioners quoted by CIO on June 18, 2025, described integration work associated with disconnected systems, alongside the maintenance, staff-education and payment burdens of additional tools. Their commentary illustrates concerns to investigate, rather than measuring prevalence or proving causal effects. Read alongside the survey, it gives the review two distinct questions: what obligations does each tool create, and who has authority to decide whether they remain justified?
Assign those judgments explicitly. Operations should accept the proposed workflow. The technical owner should assess integrations, data handling and recovery. Finance should verify contracts and the cost case. Process owners should validate required capabilities, with control or compliance owners involved wherever obligations require them.
Name one accountable decision owner to resolve trade-offs. Record each decision’s rationale, supporting observations, unresolved conditions, implementation owner and review date. Shared participation should not mean shared ambiguity: specify who approves cutover and who can stop it.
Migrate in stages and preserve a recovery route
Prioritize candidates with understood dependencies, manageable interruption risk and a credible recovery route. Do not use subscription price or user count as a proxy for operational risk. Before scheduling a change, require owners to explain how affected work will continue and how they will verify it.
Confirm scope, owner, dependencies and acceptable interruption.
Map data, integrations, controls and the destination workflow.
Validate required work, records and connections.
Use agreed acceptance criteria and rollback conditions.
Verify outcomes and retention obligations before closure.
Recommended controls, not a promise of uninterrupted operation. Pause when a gate is unmet.
Establish readiness, test within a bounded scope, control cutover and review before the next migration.Define rollback in operational terms: what triggers it, who authorizes it, how users regain access and how records created after cutover will be handled. Confirm the limits on restoring the previous state before approval. Keeping the old account open is not enough to demonstrate recovery readiness.
After cutover, review workflow completion, data reconciliation, integration behavior, support issues and actual costs against the agreed criteria. Confirm retention and access obligations before deleting records or ending the service. Use the findings to decide whether the next migration should proceed, change scope or wait.
Ask for a portfolio decision register before a cancellation list. For each proposed retirement, it should answer: who accepts the changed workflow, what evidence permits cutover and what happens if acceptance criteria are missed? Until those answers are clear, authorize investigation rather than removal.
