Application Portfolio Rationalization: [Portfolio or business unit]

Application portfolio assessment and rationalization plan using the TIME model (Tolerate, Invest, Migrate, Eliminate), a commonly used portfolio classification attributed to Gartner: inventory, weighted business value and technical health scoring, cost and risk data, a disposition per application, a quadrant chart, a decision roadmap, a decommissioning checklist and benefits tracking. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Introduction
2. Application inventory
3. Scoring rubric
4. Cost data
5. Risk assessment
6. TIME quadrant
7. Disposition per application
8. Rationalization roadmap
9. Decommissioning checklist
10. Benefits tracking
11. Governance
12. Glossary and references

1. Introduction

1.1 Purpose and triggers

This document assesses the applications of [Portfolio] and recommends a disposition for each one, so that [Organisation] can [reduce run cost by a target amount, remove unsupported software, consolidate duplicated capabilities after the merger, fund the applications that drive the strategy]. Triggers for this round: [end of vendor support for APP-044, budget target for FY YYYY, findings FND-01 and FND-02 of the capability map].

1.2 Scope

• In scope: [all business applications owned by the retail business unit, including SaaS subscriptions].
• Out of scope: [infrastructure platforms and end-user tools, which have their own lifecycle process].
• Unit of assessment: one application as known to its users, which may contain several technical components.

1.3 The TIME model

The TIME model classifies each application on two axes, business value and technical health (often called technical fit or technical quality), into four dispositions:

The model is widely used in application portfolio management and is commonly attributed to Gartner. Wording of the four dispositions varies between sources; this document uses the definitions in the table above. Migrate decisions are detailed further with the 7 Rs in the Legacy Modernization Assessment (architecture/modernization-assessment).

1.4 Related documents

2. Application inventory

2.1 Inventory fields

2.2 Inventory

3. Scoring rubric

3.1 Business value criteria

3.2 Technical health criteria

3.3 Score calculation

Each axis score is the weighted sum of the criterion scores, where each criterion score is an integer from 1 to 5 and the weights on each axis sum to 1:

Both scores therefore range from 1.0 to 5.0. An axis score of 3.0 or more counts as high. A score within 0.25 of the threshold (from 2.75 to 3.25) is borderline and needs a review panel decision recorded in section 7.

3.4 Worked example (APP-012 CRM)

Example: criterion scores BV-1 to BV-4 = 4, 4, 5, 3 and TH-1 to TH-5 = 2, 2, 3, 1, 2.

High business value and low technical health place APP-012 in Migrate.

3.5 Scores for all applications

4. Cost data

4.1 Cost categories

Include licences or subscriptions, infrastructure and hosting, support and maintenance contracts, internal staff effort (in full-time equivalents converted at a standard rate), and an allocated share of shared platforms. Exclude one-off project costs, which belong in section 8 and in the TCO analysis.

4.2 Annual run cost

Cost allocation method: [describe how shared platform and staff costs were allocated, and the standard rate per full-time equivalent].

5. Risk assessment

6. TIME quadrant

The chart plots technical health on the horizontal axis and business value on the vertical axis. Coordinates are derived from table 3.5 with the conversion (score minus 1) divided by 4, rounded to two decimals.

Observations: [Example: two high-value applications sit in Migrate and hold 47 percent of run cost (USD 1,370,000 of USD 2,910,000); APP-061 is close to the Invest boundary and the panel confirmed Migrate because of RSK-03; APP-090 is close to the Invest boundary and stays Tolerate].

7. Disposition per application

7.1 Capability overlap check

For each capability supported by more than one application, state which application becomes the system of record and what happens to the others.

8. Rationalization roadmap

The dates in the chart are illustrative; replace them with your plan.

9. Decommissioning checklist

Application: [APP-nnn name]. Decommissioning owner: [@owner].

9.1 Before switch-off

• Business owner has signed off the retirement date.
• All users and user groups have a replacement and have been informed with at least [N] weeks' notice.
• Every inbound and outbound interface is listed, its consumers are informed, and each one is moved or switched off.
• Data to be migrated has been migrated and reconciled, with record counts and sample checks signed off.
• Data to be retained has an archive location, a retention period based on the records schedule, and a tested way to retrieve it.
• Legal hold status has been checked with the legal team.
• Batch jobs, scheduled reports and monitoring alerts are listed.
• Contract notice has been served before the notice deadline.

9.2 Switch-off

• Read-only period completed (if used) with no blocking issues.
• Application access removed; accounts and service identities disabled; secrets and certificates revoked.
• DNS entries, firewall rules and load balancer configuration removed.
• Infrastructure, licences and SaaS tenants released.

9.3 After switch-off

• Data destroyed where not retained, with a destruction record.
• CMDB, capability map (section 8 of REF-01) and integration catalogue updated.
• Final cost saving confirmed with finance and recorded in section 10.
• Lessons learned recorded.

10. Benefits tracking

Example: if BEN-01 and BEN-02 are fully realised, annual run cost falls by USD 300,000 (USD 180,000 plus USD 120,000), from USD 2,910,000 to USD 2,610,000, against one-off costs of USD 960,000 for RD-01 and RD-02. Confirm the full business case in the TCO analysis.

11. Governance

New applications enter the inventory at procurement or project start, with a provisional score, a capability mapping and an intended disposition. Proposals that duplicate an Invest application need an architecture board dispensation (architecture/architecture-governance-charter).

12. Glossary and references

12.1 Glossary

12.2 References

• TIME model (Tolerate, Invest, Migrate, Eliminate): a commonly used application portfolio classification attributed to Gartner; check the source you adopt for its exact definitions.
• Related templates: Business Capability Map (architecture/business-capability-map), Legacy Modernization Assessment (architecture/modernization-assessment), Total Cost of Ownership Analysis (architecture/tco-analysis), Technology Selection (architecture/technology-selection), Technical Debt Register (architecture/tech-debt-register), Technology Radar (architecture/tech-radar).

Standard and licence note

Structure aligned with the TIME model for application portfolio rationalization (Tolerate, Invest, Migrate, Eliminate), a widely used classification commonly attributed to Gartner. The scoring criteria, weights, thresholds, checklists and all wording in this template are original and are not taken from any proprietary research; check the current definitions of any framework or tool you adopt alongside it. Gartner is a registered trademark of Gartner, Inc. Template licence: MIT.