Application Portfolio Matrix: A Worked TIME Example

Every guide to application rationalization explains the TIME model in four boxes: Tolerate, Invest, Migrate, Eliminate. Very few show what happens when you actually apply it to a real list of applications: who scores what, which grid you use, where you put the threshold, and what you do with the seventeen applications that land in "Eliminate" on a Thursday afternoon. This article does exactly that on an example portfolio of 80 applications. The company and its portfolio are fictional: every name, score and count is invented, but the numbers are consistent with each other, so you can follow the arithmetic and reuse the method.

TL;DR

• TIME sorts applications on two axes, business value and technical health, into four verdicts: Tolerate, Invest, Migrate, Eliminate.
• Score each axis with a short weighted grid (4 to 5 criteria, scale 1 to 5) and a fixed threshold, here 3.0 on both axes. Business owners score value; IT scores health.
• In our fictional 80-application portfolio, the final matrix is 18 Invest, 31 Tolerate, 14 Migrate, 17 Eliminate, after one verdict was corrected by a dependency check.
• A verdict is not a decision: every "Eliminate" needs an owner, a date and a dependency check before anything is switched off.
• Download the free TIME matrix template (XLSX) with both grids, editable weights, the verdict rule and a matrix chart that updates as you score.

What is the TIME model, in one minute?

TIME is a 2x2 classification that places each application according to its business value and its technical health, and gives each quadrant a default course of action. It is widely attributed to Gartner and used by many application portfolio management (APM) vendors; the letters stand for:

If you want the wider frame (inventory, assessment, governance, metrics), the application portfolio management guide covers it; for the cost side of rationalization (TCO, licences, quick wins), see IT rationalization: reduce your application costs. Here we stay on one thing: running the matrix itself.

The example: who is our fictional company?

Our example is a mid-sized industrial manufacturer of about 900 employees with three plants, a head office and a small IT team of eleven people. Its portfolio holds 80 applications: an ERP, a MES on the plant floor, a CRM, a PLM, payroll in SaaS, a dozen in-house tools written over fifteen years, and the usual long tail of departmental SaaS. Nobody has ever reviewed it as a whole, and the CIO wants a TIME matrix before the budget round. Again, this company does not exist; it is built to resemble the mid-sized organisations (50 to 5,000 employees) the method is aimed at.

Step 1: How do you build the list before scoring anything?

Start with one line per application, one named owner per line, and nothing else until the list is complete. Scoring a partial list produces a partial matrix that people will nonetheless treat as complete.

For each application, the minimum columns are: name, short description, category (business domain), vendor or "in-house", hosting, responsible person on the business side and on the IT side. The owner columns matter more than they look: in step 2, the business owner is the person who scores value. If a line has no owner, write "none" rather than leaving it blank; orphan applications are a finding in themselves, and the application ownership matrix explains how to settle them.

Two practical rules from the example:

• Count by business application, not by module or instance. The ERP is one line even though it covers finance, purchasing and planning. Three copies of the same label-printing tool in three plants are one line with a note.
• Decide the scope up front. Our company excludes office suites, the operating systems and pure infrastructure tools. That decision is written at the top of the sheet.

In the example, this step takes two weeks and ends with 80 lines, of which 9 have no identified business owner.

Step 2: How do you score business value?

Business value is the weighted average of four criteria scored from 1 to 5 by the application's business owner, with IT in the room to challenge but not to vote. Four criteria are enough; beyond six, scorers start averaging instead of judging.

Value score = 0.40 × criticality + 0.20 × users + 0.20 × differentiation + 0.20 × obligation.

How the example company ran it: one 90-minute workshop per business domain (six in total), each business owner scoring their own applications aloud, the IT architect asking "what happens on Monday morning if it's gone?" for every criticality score of 4 or 5. Scores 2 and 4 are allowed; they mean "between the two descriptions". The grid with all five levels described is in the template.

Step 3: How do you score technical health?

Technical health is the weighted average of five criteria scored by IT: the application manager or architect, with the security officer for the security line. Score the application as it runs today, not as it would run after the upgrade everybody has been promising.

Health score = 0.25 × support + 0.20 × debt + 0.25 × security + 0.15 × run cost + 0.15 × skills.

"Run cost" sits on the health axis on purpose: an application that costs too much to run for what it does is a technical problem, whatever its business value. Keeping cost off the value axis avoids the classic confusion between "expensive" and "important" (more on that in the pitfalls).

Step 4: How do you plot the matrix and read it?

Place each application with its value score on one axis and its health score on the other, and cut both axes at 3.0, the middle of the scale. The rule is mechanical, which is the point: nobody negotiates a quadrant, they can only challenge a score.

• Value ≥ 3.0 and health ≥ 3.0: Invest
• Value ≥ 3.0 and health < 3.0: Migrate
• Value < 3.0 and health ≥ 3.0: Tolerate
• Value < 3.0 and health < 3.0: Eliminate

The first pass on the example portfolio gave 18 Invest, 31 Tolerate, 13 Migrate and 18 Eliminate. The dependency review in step 5 moved one application from Eliminate to Migrate (the EDI gateway, below), so the final matrix of the fictional portfolio reads:

Total: 80 applications. A large Tolerate quadrant is normal: most of a portfolio works and does not matter much. That is where you avoid spending.

Here are twelve lines of the example, with the scores computed from the two grids:

Reading four typical cases

• Invest, the MES (4.60 / 3.45). Production stops without it and it carries the plants' know-how. Its health is good but not great (security 3: shared operator accounts on the floor). Invest does not mean "leave it alone": the first investment is the security gap.
• Migrate, the in-house quality app (4.40 / 1.55). Batch traceability required by customers runs on a framework out of support, maintained by one developer. The function is not in question; the technology is. The verdict becomes a replacement project, not a retirement.
• Tolerate, visitor management (1.60 / 4.00). A cheap, well-run SaaS that nobody depends on. Renew it, do not integrate it with anything, and look at it again next year.
• Eliminate, the second project tool (1.00 / 2.25). Marketing adopted it while the rest of the company uses another tool; four users, no obligation, no differentiation. Its projects can move to the main tool.

Do it by hand with the template, or keep the portfolio, owners and verdicts in a shared repository: UrbaHive's free plan (1 user, 25 applications, no credit card) is enough to try it on your critical perimeter.

Step 5: How do you turn verdicts into decisions?

A verdict says which direction an application should go; a decision adds a person, a date and a checked list of dependencies. Without those three, an "Eliminate" stays in the spreadsheet for years.

For each quadrant, the example company writes one kind of decision:

The 17 Eliminate applications fall into three groups in the example: 7 duplicate a function another application already covers, 6 are barely used anymore, and 4 were already replaced but never switched off. They are scheduled in three waves: 6 in the next quarter (the unused and already-replaced ones with no data to migrate), 6 in the following quarter, and 5 in the second half of the year, the duplicates whose users need to move. Each one goes through the application decommissioning checklist before the switch-off date: flows, processes, data retention, contracts, accounts.

The 14 Migrate applications become 14 one-page project briefs. Four are funded this year (including the quality app), the rest are sequenced over the next two budget rounds.

This is also where the EDI gateway changed quadrant. In the first pass, business owners scored it 2.00 on value: nobody uses it directly, it has one user (the IT integrator), no differentiation. The dependency check showed that the ERP sends every supplier purchase order through it. Its process criticality went from 2 to 5, its value score from 2.00 to 3.20, and its verdict from Eliminate to Migrate. Switching it off as planned would have stopped purchasing.

What are the pitfalls of a TIME matrix?

The three mistakes that cost the most are scoring alone, ignoring dependencies, and confusing cost with value.

• Scoring alone. An architect who scores 80 applications on both axes produces a matrix nobody owns, and every Eliminate verdict gets contested by its users. Split the axes: business scores value, IT scores health, and each side can challenge the other's scores in the workshop, not afterwards.
• Ignoring dependencies. Business value is scored by people who see the screen, not the plumbing. Integration components, file transfers, batch jobs and small databases are systematically under-scored, like the EDI gateway. Check incoming flows and the processes attached to every application before confirming Eliminate or Migrate.
• Confusing cost with value. An expensive application is not more valuable, and a cheap one is not less. Keep cost on the health axis (run cost) or next to the matrix as a separate column, never inside the value score.
• Moving the threshold to get the answer you wanted. If the matrix says 31 Tolerate and that feels wrong, challenge individual scores, not the 3.0 cut. Applications scored between 2.8 and 3.2 on either axis deserve a second look; mark them, do not reclassify them by hand.
• Treating the matrix as a one-off. Scores age: a vendor announces end of support, a new regulation raises the obligation score. Re-score yearly, and re-score an application whenever its owner, vendor contract or hosting changes.

How does UrbaHive help with a TIME assessment?

UrbaHive does not compute TIME scores, verdicts or costs: the assessment stays your method, with your grid. What it does is hold the portfolio the assessment runs on, in a shared repository, connected to the flows, servers, processes and people that the dependency check needs.

There is no Excel or CSV import. To load a spreadsheet such as the template, you enter the records by hand or ask an AI agent connected through the MCP server (with the write scope enabled) to read the file and create the applications and their custom-field values; every call is recorded in the audit log, and no MCP tool can delete an application, a flow or any other object of the map.

On quotas: the free plan covers 25 applications, enough to run the method on your critical perimeter. A full 80-application portfolio like the example needs the Starter plan (29 € per month excl. VAT, 100 applications, 5 users). Every feature is in every plan.

FAQ

What does TIME stand for?

Tolerate, Invest, Migrate, Eliminate. Each letter is the default course of action for one quadrant of a matrix that crosses business value with technical health. Some vendors replace Migrate with Modernize; the logic is the same.

How often should the portfolio be assessed?

Once a year for the whole portfolio, ideally a few weeks before the budget round so Migrate and Invest verdicts can be funded. In between, re-score an application when something material changes: end of support announced, new owner, contract renewal, acquisition of a tool that overlaps.

Who should score business value?

The business owner of each application, in a short workshop where IT can ask questions and challenge. IT should score technical health. If an application has no business owner, that is the first thing to fix; in the meantime, score it with the manager of the main user team and flag the line.

What is the difference between TIME and Gartner's Pace-Layered Application Strategy?

They answer different questions. TIME says what to do with each application (keep, invest, replace, retire) based on value and health. Gartner's Pace-Layered Application Strategy, sometimes written "PACE" although it is not an acronym, classifies applications by how fast they need to change: systems of record (slow change, core transactions), systems of differentiation and systems of innovation (fast change, experiments). They combine well: pace layers tell you how to govern an Invest application, TIME tells you whether it deserves investment at all.

Start with the template, keep it alive in a repository

A TIME matrix is a two-week inventory, six workshops and a mechanical rule; the hard part is keeping owners, verdicts and dependencies current once the budget round is over. Start with the free TIME matrix template: it computes the scores and verdicts and plots the matrix for you. When the portfolio needs to be shared and connected to flows, processes and owners, UrbaHive is built for mid-sized organisations (50 to 5,000 employees); you can start in a couple of hours on the free plan: 1 user, 25 applications, no credit card. Create your UrbaHive account.