In Gartner's TIME model for application portfolio rationalization, what do the four categories — Tolerate, Invest, Migrate, Eliminate — mean, and what inputs drive assigning an application to one of them?

## The two axes The TIME model, popularized by Gartner, is a two-axis classification framework for deciding what to do with every application in a portfolio. 1. **Business fitness** — the first axis measures how well the application currently serves the business need it was built for: functional coverage of present-day requirements, user or customer satisfaction, and strategic alignment with where the business is heading. 2. **Technical fitness** — the second axis measures the health of the underlying implementation: vendor and platform support status, security posture, scalability headroom, code quality and accumulated technical debt, and total cost of ownership. ## The four quadrants Plotting an application on both axes places it in one of four quadrants, each with a distinct prescribed action: | Quadrant | Position on the axes | Prescribed action | |---|---|---| | **Invest** | high business fit, high technical fit | Keep funding enhancements because it's both valuable and healthy | | **Tolerate** | low business fit, high technical fit | Leave it running with minimal spend because it's technically sound but not strategically important | | **Migrate** | high business fit, low technical fit | The business genuinely needs this capability but the current implementation — say, an unsupported mainframe COBOL system — is a liability, so the work is to replatform or rebuild it onto healthier technology without losing the capability | | **Eliminate** | low business fit, low technical fit | Retire it, since it's neither valuable nor healthy | ## How an application gets classified Mechanically, classifying an application starts with a scoring workshop or structured questionnaire involving both the business owner and an architect, because business fitness and technical fitness require different expertise to assess honestly. Each axis is usually built from several weighted criteria combined into a single 1-to-5 or 1-to-10 composite score, and the two composite scores determine the quadrant. The output isn't just a label — each quadrant implies a concrete roadmap action: - **Invest** items get enhancement budget. - **Tolerate** items get a spending freeze and only critical patching. - **Migrate** items get a modernization project with a target architecture and funded timeline. - **Eliminate** items get a sunset plan covering data migration, user transition, and a hard decommission date. ## Why the framework exists TIME exists because unmanaged application portfolios grow without anyone forcing an explicit trade-off: teams naturally lobby to keep funding what they already have, and without a repeatable framework, investment decisions default to whoever argues loudest rather than to actual business value and technical risk. By forcing every application through the same two-axis lens, TIME creates a common vocabulary that lets an investment committee compare a payroll system against an internal reporting tool on the same footing and make portfolio-wide trade-offs rather than one-off local decisions. ## The trade-off: simplicity versus nuance The central trade-off of TIME is simplicity versus nuance. Reducing an entire application's worth to two numbers and four buckets is exactly what makes it communicable to executives who don't have time for a full architecture review — but that same simplicity means: - **quadrant boundaries are fuzzy** — an application scoring 5.4 versus 5.6 on a six-point scale can land in different quadrants for essentially arbitrary reasons; - **scores are often subjective** and politically influenced; - **the model says nothing about dependencies or sequencing** — an application that scores cleanly in the Eliminate quadrant might be structurally impossible to retire this year if five other systems still integrate with it. ## Failure modes The most common failure modes show up over time rather than at the moment of classification. - **Scoring gets gamed.** Application owners know their budget and headcount ride on the outcome, so business-fitness scores drift upward regardless of actual usage, and technical-debt disclosures get softened to avoid a mandated migration. - **Tolerate becomes a permanent parking lot.** Once something is labeled 'fine as is,' nobody revisits it, and applications sit there for years past the point their technical fitness has quietly degraded further. - **Migrate items pile up without ever getting funded**, because migration work is expensive, produces no new visible feature, and consistently loses budget priority against net-new initiatives — so the Migrate quadrant becomes a list of things everyone agrees are risky and nobody funds. - Organizations frequently treat TIME classification as a **one-time exercise** rather than an annual or biannual re-scoring cycle, so the labels become stale exactly as the underlying technology and business needs shift. ## A concrete example A concrete example: a retail bank runs a TIME classification exercise across three hundred applications and finds forty percent land in the Migrate quadrant, running on end-of-life mainframe COBOL systems that the business still critically depends on for core banking functions. Rather than trying to fund all forty percent at once, the bank prioritizes the Migrate backlog by multiplying business criticality by technical risk, and funds a three-year modernization wave starting with the highest-risk, highest-criticality systems first.