TIME Model (Tolerate, Invest, Migrate, Eliminate) for App Portfolios

The application rationalization meeting starts at 9 AM. By 11 AM, the team has classified twelve of the four hundred applications in scope. Three of those twelve classifications have already been contested, revised, and contested again. The COBOL batch program that runs payroll is clearly not Eliminate, but is it Tolerate or Invest? The legacy billing system that everyone agrees is technically inadequate is clearly Migrate, but migrate to what, and what happens to the seventeen programs that depend on it? The meeting is scheduled until noon. At noon, someone suggests continuing next week. By the following month, the initiative has quietly stopped producing output.

The Gartner TIME model is the most widely used application portfolio management framework in enterprise IT. It sorts every application in the portfolio into one of four dispositions, Tolerate, Invest, Migrate, Eliminate, using two scoring dimensions: business value and technical fit. The framework is logically sound, broadly applicable, and cited by the US federal CIO Council’s Application Rationalization Playbook as a recommended methodology. It also fails in practice more often than it succeeds, for a reason that the framework’s advocates mention but rarely develop: the classifications are only as good as the evidence behind them. Without structural evidence, real dependency counts, real complexity measurements, real business value data derived from execution traces rather than owner interviews, TIME classifications become organizational politics. Placement arguments start at Migrate and Eliminate, where someone’s favorite application is on the line, and they never resolve.

The Model: Two Axes, Four Dispositions

The TIME model plots every application on a 2×2 matrix. The horizontal axis is technical fit, how well the application’s current technical implementation supports its intended function: architecture quality, maintainability, integration capability, security posture, operational reliability. The vertical axis is business value, how important the application’s function is to the organization’s business operations, revenue generation, regulatory compliance, or strategic objectives.

	High Technical Fit	Low Technical Fit
High Business Value	INVEST, Fund it. The application is both strategically important and technically sound. Invest to maintain its lead.	MIGRATE, The business needs it, the technology is wrong. Replace the platform, not the function.
Low Business Value	TOLERATE, Leave it alone for now. The application is healthy but not worth additional investment.	ELIMINATE, Retire it. Low value, low quality, no case for keeping it.

The simplicity is intentional. TIME is not designed to produce granular investment planning, it is designed to produce unambiguous directional decisions for every application in the portfolio. An application that cannot be clearly placed is an application that requires more information before classification is possible.

The Four Quadrant Operating Models

Each TIME disposition is not just a label, it is an operating model that determines how the organization manages the application going forward.

Invest: Maximum Value Extraction

Invest applications are the portfolio’s crown jewels: high business value, high technical fit. They justify the most aggressive investment in new features, performance optimization, integration expansion, and technical currency maintenance. An Invest application that falls behind on its technical currency, an aging runtime, an outdated security posture, an accumulating dependency debt, risks sliding into Migrate before the slide is noticed.

Operating commitments for Invest:

• Dedicated engineering capacity for feature development and technical maintenance
• First-priority security patching and compliance updates
• Architecture review board coverage for every significant change
• Proactive monitoring with SLA targets at the Tier 1 level

Migrate: Replace the Platform, Preserve the Function

Migrate applications perform a business function the organization genuinely needs, but on a technical platform that is no longer adequate, too expensive to maintain, too fragile to extend, too isolated from the modern integration landscape. The business value justifies the migration investment; the technical state makes continued investment in the current platform a poor return.

The Migrate disposition answers a specific question: is the function worth preserving? If yes, migrate. What to migrate to, and how, is a separate decision that the TIME classification does not make, it only establishes that the current platform is not the answer.

The most common Migrate scenario in legacy environments: A COBOL batch program that implements critical business logic, complex regulatory calculations, proprietary pricing rules, jurisdiction-specific tax logic, on a platform that makes it expensive to extend, test, and integrate. The logic is irreplaceable; the platform is the problem. Migrate to a modern platform that preserves the logic while providing the operational characteristics the business now requires.

Tolerate: Deliberate Inaction With an Expiration Date

Tolerate is the most misunderstood quadrant. It does not mean “this application is fine.” It means “this application’s technical quality does not justify the investment to change it right now, and its business value does not justify eliminating it.” It is a deliberate choice to accept the status quo for a defined period, not an indefinite deferral.

Tolerate is a timed hold, not a permanent state. Every application in the Tolerate quadrant should have an explicit review date, typically 12 to 18 months, and defined conditions that would trigger early reclassification: a security vulnerability that cannot be patched, a dependency retirement that forces a platform change, a business value increase that makes the application worth investing in, or a business function change that eliminates its purpose.

Organizations that treat Tolerate as permanent accumulate exactly the technical debt that the TIME model was designed to prevent. A COBOL program Tolerated in 2019 that is still in the Tolerate quadrant in 2026 has received seven additional years of deferred maintenance attention that it will eventually need to receive, either as an emergency when something breaks or as a forced Migrate when the platform can no longer be supported.

Eliminate: The Decision Everyone Makes and Nobody Executes

Eliminate is the most straightforward classification and the least executed disposition. The application has low business value and low technical fit, there is no case for keeping it. Retire it.

The execution failure is well documented: Eliminate is populated enthusiastically and acted on almost never. A 2024 portfolio review at a large financial institution produced 87 Eliminate candidates. Eighteen months later, 71 of them were still running. The gap between the classification and the decommission is where rationalization programs lose their momentum.

Three specific obstacles prevent Eliminate execution:

Hidden dependencies. The application was classified as Eliminate based on its apparent standalone status. After the classification, structural analysis reveals that twelve other programs produce output that the Eliminate candidate processes, or that three external systems send data to it through an undocumented file interface. The application is not standalone; it is the hidden infrastructure for other systems. The classification must be revisited.

Data migration blockers. The application holds data that cannot be destroyed, regulatory records with mandatory retention periods, customer data that must transfer to a successor system, historical transaction records that audit processes query annually. The data migration must precede the decommission, and data migration is expensive.

Regulatory obligations. Some applications cannot be retired even when their business value is zero, because regulatory frameworks require the capability they provide. A reporting application that produces a quarterly regulatory submission has regulatory value that does not appear in any business value survey. Until the regulatory obligation is transferred to another system, the application must run.

The Evidence Problem: Why TIME Fails Without Structural Data

The most significant failure mode in TIME implementations is what Catio’s documentation identifies precisely: placement arguments start at Migrate and Eliminate, where someone’s favorite application is on the line. Without objective evidence, every classification is a negotiation. The application owner argues for Invest. The IT team argues for Migrate. The finance team wants Eliminate. The meeting ends in Tolerate because it is the least contentious position.

Structural evidence resolves these negotiations by replacing opinion with measurement.

For technical fit scoring, the evidence that matters:

Technical Fit Indicator	Source	Moves Classification Toward
Cyclomatic complexity per program (avg)	Static code analysis	Low = higher fit, High = lower fit
Dead code percentage	Reachability analysis	High dead code = lower fit
Fan-in (inbound dependency count)	Dependency mapping	High fan-in increases Tolerate over Eliminate
Copybook sharing breadth	COPY dependency analysis	High sharing = higher coupling = lower fit
Time since last meaningful change	Git/change management log	Long dormancy may indicate dead code or stability
Security vulnerability count	SAST scan	High count = lower fit

For business value scoring, the evidence that matters:

Business Value Indicator	Source	Moves Classification Toward
Transaction volume per period	JCL execution logs, scheduler records	High volume = higher value
Downstream fan-out	Dependency mapping	High fan-out = higher value (many depend on it)
Regulatory function flag	Data classification, compliance registry	Present = minimum value floor regardless of other scores
Revenue adjacency	Data flow analysis to billing/revenue systems	Direct adjacency = higher value
User count or API call count	Access logs, network traffic	High count = higher value

The critical insight: for legacy COBOL systems, most of these indicators are not available from CMDB entries, application owner interviews, or network traffic analysis. They are available from structural analysis of the source code, execution logs, and the JCL job schedule that documents what actually runs in production and when.

Scoring Technical Fit for COBOL and Legacy Systems

Standard technical fit scoring criteria, API compatibility, cloud-native readiness, containerization support, microservices architecture, are irrelevant for COBOL batch programs. A COBOL program cannot be containerized; scoring it against cloud-native criteria produces a technical fit score of zero for every legacy program, which tells the organization nothing useful.

For COBOL and mainframe systems, the technical fit score requires COBOL-specific criteria:

Complexity score (weight: 30%): Average cyclomatic complexity across the program’s paragraphs and sections. Programs with average CC below 10 have manageable complexity; programs above 20 have structural complexity that makes maintenance expensive and risky.

Maintainability score (weight: 25%): Composite of dead code percentage, copybook sharing breadth, and duplication rate. A program with 40% dead code, 15 shared copybooks, and significant code duplication has low maintainability regardless of its functional correctness.

Dependency risk score (weight: 20%): Fan-in count weighted by the criticality of inbound dependents. A program with 50 inbound dependencies from Tier 1 programs has high dependency risk, changes to it require coordinating 50 downstream programs.

Currency score (weight: 15%): COBOL dialect and compiler version currency, JCL syntax modernity, and database interface (embedded SQL vintage, VSAM vs DB2, batch-only vs batch+CICS). Programs written in COBOL-85 syntax with DB2 embedded SQL are more current than programs written in COBOL-74 with VSAM-only file access.

Security posture score (weight: 10%): Hardcoded credentials presence, unprotected file access, absence of FILE STATUS checking, and SQL injection exposure in dynamic SQL construction.

Technical Fit Score = (100 - complexity_score) × 0.30
                    + maintainability_score × 0.25
                    + (100 - dependency_risk) × 0.20
                    + currency_score × 0.15
                    + security_score × 0.10

Where each component is scored 0-100, with 100 being best.

This scoring formula produces a 0-100 technical fit score derived from structural code analysis rather than from qualitative assessment. Two applications with identical functions but different structural characteristics will produce different technical fit scores, and those scores will accurately reflect the different investment required to maintain and extend each.

The Tolerate Drift Problem: Governance for the Holding Quadrant

Tolerate is the quadrant that accumulates debt over time in every organization that uses TIME without explicit Tolerate governance. The mechanism is simple: an application enters Tolerate because it is not worth changing, then it remains in Tolerate indefinitely because changing it is never the most urgent priority.

A Tolerate governance discipline prevents indefinite deferral:

Condition-based reclassification triggers:

• Security vulnerability identified that cannot be patched within 30 days → review for Migrate or Eliminate
• Vendor announces end-of-life for a platform component the application depends on → review for Migrate
• Business value score increases above threshold (new regulatory requirement, business model change) → review for Invest or Migrate
• Dependency retirement forces interface change → review for Migrate or Eliminate
• Dead code analysis reveals the application is effectively inactive → review for Eliminate

Time-based review cadence:

• Applications enter Tolerate with a 12-month review date
• At the 12-month review, the application is explicitly reclassified or explicitly re-Tolerated with a new 12-month date
• Re-Toleration requires a written rationale that documents why the conditions have not changed
• An application that has been Re-Tolerated more than twice without reclassification triggers an escalation to the architecture review board

The Tolerate registry: A maintained list of every Tolerate application with its classification date, review date, owner, and the condition set that would trigger reclassification. This registry is reviewed at every architecture review board meeting, not just at the annual portfolio review.

Making Eliminate Executable: Closing the Decommission Gap

The gap between “classified as Eliminate” and “successfully decommissioned” is where rationalization programs stall. Closing that gap requires treating each Eliminate decision as a project with defined scope, dependencies, and success criteria, not as a conclusion.

The Eliminate execution checklist:

• Dependency verification complete: Static analysis confirms zero inbound production dependencies (not just zero documented dependencies, structurally verified zero)
• Data disposition plan approved: Regulatory retention requirements identified, data migration or archival plan approved by legal and compliance
• Downstream notification complete: Every consuming system’s owner notified and confirmed no active dependency
• Regulatory obligation check complete: No active regulatory submission, audit, or compliance requirement depends on the application
• Decommission owner assigned: Named individual responsible for executing the decommission, not just the classification decision
• Rollback plan defined: Procedure for restoring service if the decommission reveals an undiscovered dependency
• Decommission date committed: Specific date on the IT calendar, not “when we get to it”

The structural analysis gate: No Eliminate decision proceeds to decommission planning until a structural analysis confirms zero inbound dependencies from production execution paths. The most common cause of Eliminate execution failure is discovering a dependency after the decommission announcement that forces a reversion. Structural dependency analysis before the announcement prevents this.

The TIME Reassessment Cycle

TIME classifications are not permanent. Business value changes as the organization’s strategy evolves. Technical fit changes as the application is maintained, extended, or allowed to age. The model is a snapshot; the portfolio requires a moving picture.

Annual full reassessment: Every application in the portfolio is scored against the current business value and technical fit criteria. Classifications that have not changed in three consecutive years are examined specifically, either the application is genuinely stable (document why) or the assessment is not capturing change that is occurring.

Event-triggered reassessment: Specific events trigger immediate reclassification review:

• Merger or acquisition (new portfolio combination)
• Regulatory change affecting compliance obligations
• Major platform end-of-life announcement (database, operating system, runtime)
• Significant business model change (new product line, market exit, organizational restructuring)
• Security incident involving the application

Change log discipline: Every reclassification is logged with: previous classification, new classification, date, evidence that drove the change, and approver. The classification history of each application is the audit trail that demonstrates the portfolio is actively managed rather than categorized and forgotten.

How SMART TS XL Provides the Evidence for TIME Classification

The TIME model’s classification decisions are only as good as the evidence behind them. For modern applications with CMDB coverage, API monitoring, and documented architectures, that evidence is accessible. For legacy COBOL portfolios where the CMDB is incomplete, the owners have retired, and the dependency structure is undocumented, the evidence must come from structural analysis of the code itself.

SMART TS XL’s static code analysis produces the technical fit inputs that COBOL scoring requires: cyclomatic complexity per program, dead code percentage, security pattern findings (hardcoded credentials, unprotected file access), and COBOL dialect currency. These metrics are derived from the source code, not from developer estimates, and they do not depend on anyone remembering what the application does.

The application dependency mapping produces the fan-in counts that prevent premature Eliminate decisions and the fan-out counts that support business value scoring. An application with 45 inbound dependencies from production programs is not a safe Eliminate candidate regardless of how its owner assesses its business value. The dependency count is the structural fact that overrides the classification argument.

The legacy modernization analysis produces the dead code inventory that changes classifications: programs that appear in the CMDB as active applications but have zero inbound production dependencies are dead code candidates, reclassified from Tolerate to Eliminate based on structural evidence, not on business owner assessment of a program they may never have known existed.

The impact analysis capability makes the Eliminate execution checklist achievable: the structural analysis that confirms zero inbound production dependencies before any decommission planning begins. This is the gate that prevents the most common Eliminate execution failure, the undiscovered dependency that surfaces after the announcement.

The enterprise search capability makes the TIME classification process queryable throughout the reassessment cycle: find every application classified as Tolerate with a review date in the next 30 days, every application classified as Eliminate with no decommission date assigned, every application with a technical fit score below 30 that is still classified as Invest. These queries are the governance tool that keeps the TIME model an active management instrument rather than a one-time classification exercise.

A Framework Is Only as Good as Its Evidence

The TIME model’s two-axis structure is correct. Business value and technical fit are the right dimensions for application portfolio decisions. The four dispositions are the right options. The problem is not the framework, it is the evidence base that organizations bring to it.

Classifications built on interview data and CMDB estimates produce organizational debates. Classifications built on structural analysis, measured complexity, verified dependency counts, code-derived technical fitness, produce defensible decisions. The application owner who argues that their COBOL program is Invest rather than Migrate has a harder case when the structural analysis shows cyclomatic complexity averaging 35, 40% dead code, and 12 security findings. The IT team that argues a program can be Eliminated has a weaker case when the dependency analysis shows 45 inbound production dependencies.

The TIME model works when the evidence makes the case. Structural analysis of the application portfolio is how organizations build that evidence for the legacy applications that most need rationalization decisions and are least likely to have the documentation that makes those decisions easy.