Application Portfolio Rationalization Template (TIME Model)

Inventory, weighted business value and technical health rubric, run cost, risks, TIME quadrant, dispositions, roadmap, decommissioning, benefits

架构与系统设计完整TIME model (Tolerate, Invest, Migrate, Eliminate), commonly attributed to Gartnerapplication portfolio rationalization math更新于 2026年10月21日

在编辑器中打开下载 .md

使用方法: Use it when you need to decide which applications to tolerate, invest in, migrate or eliminate. Fill the inventory and agree the scoring rubric and weights before anyone scores. The main pitfall is treating the quadrant as an automatic verdict instead of confirming each disposition with its business owner.

预览

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

Field	Value
Document ID	[APR-ORG-001]
Portfolio in scope	[Business unit, domain or whole enterprise]
Inventory snapshot date	YYYY-MM-DD
Applications assessed	[Number]
Version	[0.1]
Status	[Draft / In review / Approved / Superseded]
Owner	[@enterprise-architect]
Business sponsor	[@cio]
Approvers / reviewers	[@cfo-delegate, @ciso, @portfolio-office]
Last updated	YYYY-MM-DD
Classification	[Internal / Confidential]

Approvals

Role	Name	Decision	Date
Business sponsor	[@name]	[Approved / Approved with comments / Rejected]	YYYY-MM-DD
Chief architect	[@name]	[Decision]	YYYY-MM-DD
Finance business partner	[@name]	[Decision]	YYYY-MM-DD
Security officer	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	Inventory loaded, rubric agreed
0.2	YYYY-MM-DD	[@name]	Example: First scoring round for 5 applications
1.0	YYYY-MM-DD	[@name]	Example: Dispositions approved by the architecture board

Introduction
Application inventory
Scoring rubric
Cost data
Risk assessment
TIME quadrant
Disposition per application
Rationalization roadmap
Decommissioning checklist
Benefits tracking
Governance
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:

Disposition	Business value	Technical health	Typical action
Tolerate	Low	High	Keep running with minimal change and spend; review again next cycle
Invest	High	High	Fund enhancement and scaling; treat as a strategic platform
Migrate	High	Low	Keep the business function but move it to a better platform, by re-platforming, refactoring or replacement
Eliminate	Low	Low	Retire, after moving any remaining users and data elsewhere

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

ID	Document	Relationship
REF-01	Business Capability Map (`architecture/business-capability-map`)	Capability IDs and strategic importance
REF-02	Total Cost of Ownership Analysis (`architecture/tco-analysis`)	Detailed cost of replacement options
REF-03	Technical Debt Register (`architecture/tech-debt-register`)	Evidence for technical health scores
REF-04	Technology Radar (`architecture/tech-radar`)	Status of underlying technologies
REF-05	Architecture Roadmap and Transition Architectures (`architecture/architecture-roadmap-transition`)	Places decisions on the enterprise roadmap

2. Application inventory

2.1 Inventory fields

Field	Description	Source
Application ID	Stable identifier `APP-NNN`	CMDB or APM tool
Name and short description	What users call it and what it does	Application owner
Business owner	Accountable business leader	Organisation directory
Technical owner	Accountable delivery or operations lead	CMDB
Capabilities supported	Capability IDs from REF-01	Capability map
Users	Number of active users and user groups	Identity provider logs
Deployment model	On-premises, IaaS, PaaS, SaaS	CMDB
Technology stack	Language, framework, database, middleware	Technical owner
Vendor and contract	Vendor, licence model, renewal date, notice period	Procurement
Lifecycle status	Vendor support end date, internal status	Vendor, technology radar
Interfaces	Number and type of integrations	Integration catalogue
Data classification	Highest data classification held	Data catalogue
Annual run cost	See section 4	Finance

2.2 Inventory

ID	Name	Capabilities	Business owner	Users	Deployment	Vendor support end	Interfaces
APP-012 (Example)	CRM	CAP-03.02, CAP-03.03	[@head-of-service]	850	On-premises	YYYY-12-31	14
APP-020 (Example)	Rating engine	CAP-04.02	[@chief-actuary]	60	PaaS	Supported	6
APP-044 (Example)	Broker portal	CAP-03.02	[@head-of-distribution]	120	On-premises	Ended YYYY-06-30	5
APP-061 (Example)	Claims system	CAP-06.01, CAP-06.02, CAP-06.03	[@head-of-claims]	400	IaaS	YYYY-06-30	22
APP-090 (Example)	ERP	CAP-07	[@cfo]	300	SaaS	Supported	18
[APP-nnn]	[Name]	[CAP IDs]	[@owner]	[Users]	[Model]	[Date or status]	[Count]

3. Scoring rubric

3.1 Business value criteria

ID	Criterion	Weight	1 (low)	3 (medium)	5 (high)
BV-1	Strategic alignment	0.30	Supports no strategic objective	Supports a core capability	Enables a differentiating capability
BV-2	Functional fit	0.25	Users rely on workarounds	Meets most needs	Fully meets needs, liked by users
BV-3	Business criticality and usage	0.25	Occasional use, outage tolerable for days	Daily use, outage tolerable for hours	Outage stops revenue or customer service
BV-4	Regulatory or contractual necessity	0.20	No obligation depends on it	Supports reporting obligations	Required to meet a legal obligation

3.2 Technical health criteria

ID	Criterion	Weight	1 (poor)	3 (adequate)	5 (good)
TH-1	Architecture and maintainability	0.25	Monolith with no tests, few people understand it	Modular in parts, some tests	Modular, well tested, documented
TH-2	Security posture	0.25	Known critical vulnerabilities without fixes	Patched, some gaps in controls	Meets security architecture standards
TH-3	Reliability and performance	0.20	Frequent incidents, misses targets	Occasional incidents	Meets service level objectives
TH-4	Vendor and lifecycle status	0.15	Unsupported or end of life	Support ends within 2 years	Supported, roadmap aligned
TH-5	Data and integration quality	0.15	Point-to-point, poor data quality	Mixed	Standard interfaces, good data quality

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:

BV = \sum_{i=1}^{4} w_i \, s_i, \qquad TH = \sum_{j=1}^{5} v_j \, t_j, \qquad \sum_i w_i = \sum_j v_j = 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.

BV = 0.30(4) + 0.25(4) + 0.25(5) + 0.20(3) = 1.20 + 1.00 + 1.25 + 0.60 = 4.05

TH = 0.25(2) + 0.25(2) + 0.20(3) + 0.15(1) + 0.15(2) = 0.50 + 0.50 + 0.60 + 0.15 + 0.30 = 2.05

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

3.5 Scores for all applications

ID	BV-1	BV-2	BV-3	BV-4	BV	TH-1	TH-2	TH-3	TH-4	TH-5	TH	Quadrant
APP-012 (Example)	4	4	5	3	4.05	2	2	3	1	2	2.05	Migrate
APP-020 (Example)	5	4	4	4	4.30	4	4	4	4	3	3.85	Invest
APP-044 (Example)	2	2	2	1	1.80	2	1	2	2	2	1.75	Eliminate
APP-061 (Example)	5	3	5	4	4.30	3	3	3	2	3	2.85	Migrate (borderline TH)
APP-090 (Example)	3	3	3	2	2.80	4	4	4	3	4	3.85	Tolerate (borderline BV)
[APP-nnn]	[1-5]	[1-5]	[1-5]	[1-5]	[BV]	[1-5]	[1-5]	[1-5]	[1-5]	[1-5]	[TH]	[Quadrant]

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

ID	Licences	Infrastructure	Support contracts	Internal effort	Total annual run cost	Cost per active user
APP-012 (Example)	USD 150,000	USD 90,000	USD 60,000	USD 120,000	USD 420,000	USD 494
APP-020 (Example)	USD 110,000	USD 40,000	USD 30,000	USD 80,000	USD 260,000	USD 4,333
APP-044 (Example)	USD 50,000	USD 40,000	USD 30,000	USD 60,000	USD 180,000	USD 1,500
APP-061 (Example)	USD 400,000	USD 200,000	USD 150,000	USD 200,000	USD 950,000	USD 2,375
APP-090 (Example)	USD 700,000	USD 0	USD 100,000	USD 300,000	USD 1,100,000	USD 3,667
Total					USD 2,910,000
[APP-nnn]	[Amount]	[Amount]	[Amount]	[Amount]	[Total]	[Total / users]

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

5. Risk assessment

ID	Application	Risk	Likelihood	Impact	Rating	Treatment linked to disposition
RSK-01 (Example)	APP-044	Vendor support ended; no security patches	High	High	High	Eliminate by YYYY-QN; compensating network isolation until then
RSK-02 (Example)	APP-012	Support ends YYYY-12-31 and key-person dependency for customisations	Medium	High	High	Migrate; extend support contract as fallback
RSK-03 (Example)	APP-061	Vendor support for current major version ends YYYY-06-30	Medium	High	High	Upgrade path in migration plan
RSK-04 (Example)	APP-090	Customisations block vendor upgrades	Low	Medium	Medium	Tolerate with a no-new-customisation rule
[RSK-nn]	[APP ID]	[Risk]	[Low / Medium / High]	[Low / Medium / High]	[Rating]	[Treatment]

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

ID	Quadrant from scores	Final disposition	Override reason	Target state	Decision date	Decision owner
APP-012 (Example)	Migrate	Migrate		Replace with SaaS CRM; consolidate APP-044 users	YYYY-MM-DD	[@head-of-service]
APP-020 (Example)	Invest	Invest		Extend to new usage-based products (INV-02)	YYYY-MM-DD	[@chief-actuary]
APP-044 (Example)	Eliminate	Eliminate		Broker users move to the new CRM partner portal	YYYY-MM-DD	[@head-of-distribution]
APP-061 (Example)	Migrate (borderline)	Migrate	Panel review: RSK-03 outweighs borderline score	Re-platform to supported version on managed cloud	YYYY-MM-DD	[@head-of-claims]
APP-090 (Example)	Tolerate (borderline)	Tolerate	Panel review: borderline BV confirmed; finance is a commodity capability (CAP-07)	Keep; freeze customisation; review next cycle	YYYY-MM-DD	[@cfo]
[APP-nnn]	[Quadrant]	[Tolerate / Invest / Migrate / Eliminate]	[Reason or blank]	[Target]	YYYY-MM-DD	[@owner]

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.

Capability	Applications	Chosen system of record	Others
CAP-03.02 (Example)	APP-012, APP-044	New SaaS CRM (replacing APP-012)	APP-044 eliminated
[CAP ID]	[APP IDs]	[APP ID]	[Disposition]

8. Rationalization roadmap

ID	Decision	Dependencies	Contract or support date	One-off cost	Start	End	Status
RD-01 (Example)	Eliminate APP-044	Partner portal in new CRM (RD-02 phase 1)	Support ended	USD 60,000	YYYY-MM	YYYY-MM	Planned
RD-02 (Example)	Migrate APP-012	Data cleansing of customer masters	Support ends YYYY-12-31	USD 900,000	YYYY-MM	YYYY-MM	Approved
RD-03 (Example)	Migrate APP-061	Landing zone ready	Support ends YYYY-06-30	USD 700,000	YYYY-MM	YYYY-MM	Approved
[RD-nn]	[Decision]	[Dependencies]	[Date]	[Cost]	YYYY-MM	YYYY-MM	[Status]

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

ID	Benefit	Linked decision	Baseline	Target	Target date	Realised to date	Owner
BEN-01 (Example)	Run cost removed by retiring APP-044	RD-01	USD 180,000 per year	USD 0	YYYY-MM-DD	[Amount]	[@head-of-distribution]
BEN-02 (Example)	Net run cost change for CRM after replacement	RD-02	USD 420,000 per year	USD 300,000 per year	YYYY-MM-DD	[Amount]	[@head-of-service]
BEN-03 (Example)	Applications unsupported or losing vendor support within the plan period	RD-01, RD-02, RD-03	3	0	YYYY-MM-DD	[Number]	[@enterprise-architect]
BEN-04 (Example)	Customer masters for CAP-03.02	RD-01, RD-02	2 in this portfolio	1	YYYY-MM-DD	[Number]	[@head-of-data]
[BEN-nn]	[Benefit]	[RD IDs]	[Baseline]	[Target]	YYYY-MM-DD	[Realised]	[@owner]

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

Activity	Frequency	Forum	Owner
Inventory refresh from CMDB and procurement	Quarterly	Portfolio office	[@portfolio-office]
Full rescoring	Annually, before budget planning	Architecture board	[@enterprise-architect]
Rescoring after a major change or incident	As needed	Architecture board	[Application owner]
Weight and threshold changes	Only by board decision, recorded in Revision history	Architecture board	[@chief-architect]
Benefits review	Each portfolio review	Portfolio board	[@cfo-delegate]

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

Term	Meaning in this document
Application portfolio management	Ongoing management of the set of applications as an investment portfolio
Rationalization	Reducing and improving the portfolio by keeping, consolidating, replacing or retiring applications
Business value	Weighted score of strategic alignment, fit, criticality and necessity (section 3.1)
Technical health	Weighted score of maintainability, security, reliability, lifecycle and integration quality (section 3.2)
Disposition	The TIME classification confirmed for an application
System of record	The single authoritative application for a set of business data
Run cost	Fully loaded annual cost of operating an application

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.