Application Portfolio Rationalization: Why Counting Your Applications Is Not the Same as Deciding About Them

The rationalization exercise was supposed to take three months. It took eleven. The final deliverable was a spreadsheet with 847 rows, a colour-coded risk column, and a column marked "Decision" that was blank in 791 of them. The steering committee thanked the team, filed the document, and scheduled a follow-up for the following quarter. That quarter became four. The spreadsheet is still open in a browser tab somewhere, last updated fourteen months ago. This is not an unusual story. It is, in most large organisations, the default outcome of application portfolio rationalization done without a decision-forcing structure.

The pattern repeats so reliably that it has become a kind of institutional ritual: the inventory is commissioned, consultants are brought in, data is gathered from system owners who are too busy and too territorial to give accurate numbers, and eventually a document is produced that describes the problem in great detail without resolving it. The organisation has spent real money, occupied real people, and produced something that looks like progress but is not.

The question worth asking is not how to do the inventory better. It is why the inventory keeps substituting for the decision.

What is application portfolio rationalization, and what does it actually require?

The word "rationalization" implies a rational actor making choices. It does not mean cataloguing. The difference matters because the two activities require entirely different things from the organisation. Cataloguing requires data-gathering and patience. Deciding requires authority, criteria, and the willingness to be wrong.

Gartner's application portfolio management research, which has tracked large enterprise estates for well over a decade, consistently finds organisations running between 500 and 1,000 discrete applications, with complex financial services and manufacturing estates reaching several thousand. The number is not inherently a problem. The problem is that the majority of those applications have never been assessed against a consistent set of criteria. They exist because they were built or bought, they remain because retiring them is complicated, and their cost is absorbed quietly across multiple budget lines where nobody has ever added it up.

The first thing a real rationalization requires is a decision rule, agreed before the data is gathered. Without it, the exercise will produce a list of ambiguous cases and hand them back to a committee that was ambiguous about them before the exercise started.

Gartner's TIME model (Tolerate, Invest, Migrate, Eliminate) is the most commonly used framework, and it has genuine merit precisely because it forces a four-way answer on each system rather than a binary one. Tolerating a system is a real decision. It says: this system is not worth investing in, but retiring it would cost more than leaving it alone. That is a legitimate conclusion. The limitation of TIME, as with any framework, is that it assumes the organisation has reliable data on what each system actually costs to run, who uses it, and how it connects to others. Most do not. So the first task in a real rationalization is not applying the framework but establishing the data quality problem honestly, so the decisions that follow are made on evidence rather than assumption.

Why do portfolio rationalization exercises keep producing inventories instead of decisions?

There are several structural reasons this happens, and naming them plainly is more useful than cataloguing the symptoms.

The first is scope. When a rationalization is initiated, the brief is usually "understand the estate." That is a data brief. It produces data. If the brief had been "decide what we are doing with every system above £50,000 annual running cost by the end of Q3," the exercise would have been structured differently, staffed differently, and would have produced different outputs under time pressure.

The second is ownership. In most large organisations, no single person owns the application portfolio in any meaningful sense. The CIO may nominally own it, but each system has a business sponsor, a support team, an integration dependency on three other systems, and a contract with a vendor who has a renewal coming up. Any decision about one system ripples through that network, and the people in that network have an interest in deferring. So they produce data requests, raise dependencies, and ask for more analysis. The exercise expands to accommodate them.

The third is the incentive structure of whoever is running the review. This is the one that gets discussed least openly. If the firm conducting your rationalization also offers to build the replacements, it has a structural interest in finding more things that need replacing. This is not a character problem; it is a geometry problem. The recommendation follows the revenue model. That does not mean such firms produce dishonest work, but it does mean the reader of their output should ask what a rationalization conducted by someone with nothing to sell on the back of it would have concluded differently.

The fourth is the absence of a forcing function. Rationalization without a date is a workshop that never ends. The steering committee meets, reviews the latest analysis, identifies three more data gaps, and schedules another meeting. Without a deadline attached to a consequence, the default is always more information.

How should costs be counted when assessing an application?

One of the most consistent findings in application portfolio management research is that organisations significantly undercount the cost of their legacy estate. The licence invoice is real and visible. Everything else is embedded in team budgets, incident logs, and the unlogged hours that experienced staff spend every week managing systems that do not behave cleanly.

Consider a typical mid-sized enterprise with an order management system that is twelve years old. The licence cost is £180,000 per year. Visible. On the budget. But the system also requires a full-time integration developer to maintain the connections to three downstream systems, because the API layer was written before modern standards existed and nobody has touched it since. That person costs £85,000 per year fully loaded. The system generates roughly eight significant incidents annually, each requiring twelve hours of senior developer time to resolve. At £600 per day for senior developer time, that is another £36,000. And because the system cannot be changed quickly, the product team has stopped requesting improvements to the order process and is routing workarounds through a separate tool that costs £40,000 per year and handles 15% of what the original system should have handled.

The licence line says £180,000. The full count is closer to £340,000, before you factor in what the business is not doing because the system cannot support it. A rationalization that only reads the licence invoice will systematically underestimate the case for change, and will consistently make "leave it alone" look cheaper than it is.

This is not an argument for modernizing everything. Some systems with high licence costs are genuinely worth running because retiring them would cost more. The point is that the decision needs the full number, not the convenient one.

What does a rationalization exercise look like when it is working?

The temptation when looking at a 600-application estate is to believe that all 600 must be assessed before any decision can be made, because one might connect to another, and changing one might affect the others. This logic is not wrong, but it is paralyzing when applied universally. It produces the eleven-month exercise with 791 blank decision cells.

A more reliable structure starts with triage. Of the 600 systems, how many are genuinely consequential? By cost, by risk, by strategic relevance, or by the number of users who depend on them? In most estates, that group is 10 to 20 percent of the total. The other 80 percent are either small enough to tolerate without much analysis or simple enough to retire without much disruption.

Focus the first phase of the exercise on the consequential systems. Spend serious time on those. Apply the full cost count. Map the dependencies. Get the business sponsor in the room. Make the decision. Document it with a named owner and a date. Then move to the next tier.

This approach does something the comprehensive-inventory approach rarely does: it produces a decision within a timeframe short enough that the person who made it is still in their role when implementation starts. One of the underappreciated failure modes of large rationalization exercises is that the sponsoring executive has changed by the time the recommendations need acting on, and the new person has no ownership of a process they did not commission.

A well-structured rationalization of a mid-sized estate, 100 to 400 applications, should produce its first set of decisions within eight to twelve weeks. Not the whole estate resolved, but the highest-priority systems decided with enough clarity that the organisation can begin acting. The rest follows in tranches.

When is "leave it alone" the right answer from a portfolio review?

This point is worth stating plainly because it runs counter to the incentive of almost everyone who gets paid to conduct rationalization work.

Some systems should stay exactly as they are. They run a business process that does not change often, they have been stable for years, they are well understood by the team that operates them, and the cost of replacing them, in money, in disruption, and in risk, outweighs any conceivable benefit. For these systems, the right output of a portfolio review is a note that says: tolerate, review again in three years, do not invest further.

Gartner's TIME framework explicitly includes "Tolerate" for this reason. A system in toleration is not a failure of rationalization. It is a legitimate allocation decision. The budget that would have gone into replacing it goes somewhere else, into a system where the investment would produce a return.

The systems most commonly misclassified as candidates for modernization are those that are old but stable, those that use unfashionable technology but serve a process that rarely changes, and those that look alarming on a risk register because they run on an outdated platform but have never actually failed in production. Age and fashion are not the same as risk. A system that has run without incident for eight years, processes a stable workload, and has no integration pressure from newer systems may well be a "leave it alone" case, regardless of when it was written or what it was written in.

The question is not whether the system is old. The question is whether it costs more to run than it should, creates risks the business cannot accept, or prevents the business from doing something it needs to do. If the answer to all three is no, the case for intervention is not obvious, and a rationalization that concludes intervention is needed anyway should be asked to show its working.

Frequently Asked Questions

What is application portfolio rationalization?

Application portfolio rationalization is the process of deciding what to do with every system in an organisation's software estate: keep it, invest in it, retire it, or replace it. The goal is a deliberate allocation of resources, not simply a list of what exists. Most exercises stop at the list and never reach the decisions.

How is application portfolio rationalization different from an application inventory?

An inventory records what systems exist. Rationalization requires a decision about each one: does it earn its cost, does it carry risk, and does it still serve a business purpose? An inventory is an input to rationalization, not the output. Organisations that treat the finished inventory as the deliverable have done the easier half of the work and skipped the harder half.

How many applications does the average large enterprise run?

Gartner research on application portfolio management has consistently found large enterprises running between 500 and 1,000 discrete applications, with some complex estates reaching several thousand. The number itself is rarely the problem. The problem is that the majority of those applications have never been formally assessed for cost, risk, or strategic fit.

What framework should guide rationalization decisions?

Gartner's TIME model (Tolerate, Invest, Migrate, Eliminate) is the most widely used starting point. It forces a four-way decision on each application rather than a binary keep-or-cut. The limitation is that TIME assumes your organisation has the data to populate it honestly, including real running costs and actual usage figures, which many do not.

How long does an application portfolio rationalization exercise take?

A credible assessment of a mid-sized estate, typically 100 to 400 applications, takes eight to twelve weeks when done independently. Exercises run internally, or by a firm that also wants to build the replacements, routinely take longer and produce fewer decisions, because the incentives to defer and complicate are built into the engagement model.

What does application portfolio rationalization cost?

Independent assessment costs vary, but a mid-market estate typically warrants an advisory engagement in the range of £40,000 to £120,000 depending on size and data quality. That figure needs to be weighed against the cost of running the estate without a decision: licence fees, integration maintenance, and the staff hours spent working around systems that should have been retired years ago.

What is the most common reason rationalization exercises fail to produce decisions?

The exercise is scoped as a data-gathering project rather than a decision-making process. Without a named decision-maker for each system, a defined set of criteria, and a deadline, the review produces a report that documents uncertainty rather than resolving it. The steering committee defers, the systems stay, and the next annual planning cycle repeats the same conversation.

Should every application in the portfolio be rationalized at the same time?

No. Trying to decide everything at once is one of the patterns most likely to produce no decisions at all. A more reliable approach is to identify the ten to twenty systems that carry the highest cost, the highest risk, or the most strategic weight, resolve those first, and then work through the remainder in tranches. The portfolio does not need to be perfect; it needs to be moving.