Application Rationalization Process: A Step-by-Step Guide

What is the application rationalization process and how do you implement it?

The application rationalization process is a structured method for evaluating, categorizing, and optimizing an organization’s application portfolio to eliminate redundancy, reduce costs, and align with business goals. It results in a clear inventory of applications, their business value, technical health, and a roadmap for retirement, replacement, or investment. This guide provides the exact sequence practitioners use, what each step produces, and where things typically go wrong.

Step 1: Inventory and Discovery

Output: Complete list of all active applications, including ownership, version, infrastructure, and integration points.

Begin by compiling a comprehensive inventory of every application in use across departments. This includes custom-built, commercial off-the-shelf (COTS), SaaS, and shadow IT. Use automated discovery tools and manual input from business units to ensure completeness.

What usually goes wrong: Teams skip departments or fail to capture SaaS subscriptions. Shadow IT remains unlisted, leading to blind spots later. Ensure HR, finance, and remote teams are included.

This step aligns with the COBIT framework’s APO13.02 process for managing applications, which emphasizes complete visibility.

Step 2: Define Rationalization Criteria

Output: Documented scoring model based on business value, technical health, cost, and strategic fit.

Establish clear, measurable criteria for evaluating each application. Common dimensions include:

• Business criticality (e.g., supports core operations)
• User count and transaction volume
• Maintenance cost and licensing fees
• Technical debt and supportability
• Alignment with digital transformation goals

Use a weighted scoring system (e.g., 1–5 scale) to enable objective comparison.

What usually goes wrong: Criteria are too vague (e.g., “strategic importance”) or overly technical. Business stakeholders disengage if they don’t understand the scoring. Involve both IT and business leads in defining the model.

The ITIL service portfolio management practice supports this step by defining value-based service assessment.

Step 3: Assess and Score Applications

Output: Scored application register with ratings for each criterion.

Apply the scoring model to every application in the inventory. Use data where possible, avoid subjective opinions. For example, pull uptime metrics, support tickets, and license costs from existing systems.

Hold cross-functional workshops to validate scores and resolve discrepancies. Document justifications for borderline cases.

What usually goes wrong: Teams rely on memory instead of data. Outdated applications with loyal users get inflated scores. Ensure data sources are audited and scoring is transparent.

This step reflects the TOGAF Architecture Content Framework’s guidance on evaluating technology components against business architecture.

Step 4: Categorize Applications

Output: Applications grouped into action categories (Retire, Replace, Retain, Rehost, Replatform).

Based on the scores, assign each application to one of five categories:

• Retire: Low value, high cost, redundant
• Replace: Outdated but critical; needs modern alternative
• Retain: High value, low risk
• Rehost: Move to cloud without changes
• Replatform: Minor updates for cloud optimisation

Use a heat map (business value vs. technical health) to visualise decisions.

What usually goes wrong: Over-retention due to political pressure. Teams hesitate to retire legacy systems even when obsolete. Define clear thresholds to reduce bias.

Step 5: Develop Rationalization Roadmap

Output: Prioritised action plan with timelines, owners, and dependencies.

Create a multi-year roadmap showing which applications will be acted on and when. Sequence by cost savings, risk reduction, and business disruption. Include:

• Retirement dates
• Migration plans
• Budget requirements
• Stakeholder communication strategy

Link actions to broader initiatives like cloud migration or ERP consolidation.

What usually goes wrong: Roadmap lacks executive sponsorship. Budgets aren’t secured. Ensure the CIO and CFO jointly approve the plan.

The ITIL Continual Service Improvement model supports roadmap development through iterative planning.

Step 6: Execute and Monitor

Output: Updated application portfolio, cost savings reports, and compliance with target architecture.

Implement the roadmap in waves. Decommission retired applications formally, update contracts, revoke access, archive data.

Monitor KPIs such as:

• Reduction in license spend
• Decrease in support tickets
• Improvement in system uptime

Conduct annual reviews to maintain discipline.

What usually goes wrong: Teams stop after the first wave. Without governance, new shadow IT re-emerges. Assign a portfolio manager to sustain momentum.

For full methodology, including templates and scoring matrices, see OPS8593 Mastering COBIT for DevOps & Environment CoE Leads.