Why application rationalization programs stall at the inventory

AI Advisor · Free Tool

Technology Landscape Advisor

Describe your technology challenge and get an AI-generated landscape analysis: relevant technology categories, key vendors (commercial and open source), recommended architecture patterns, and a curated shortlist — all tailored to your industry, organization size, and constraints.

Vendor-neutral analysis

Architecture patterns

Downloadable Word report

Analyze My Landscape View All AI Advisors

Every large organization has run one. Some have run three.

The shape is always the same. A program is announced to reduce the application estate. A discovery exercise begins. Some months later there is a spreadsheet, or a tool, containing several thousand rows. It is genuinely impressive work, frequently the first accurate picture the organization has ever had.

And then it stops. The estate is now well documented and exactly as large as it was.

This happens often enough to be structural rather than a series of individual failures.

The inventory is the easy part, which is why it gets done

Counting applications has properties that the rest of the program does not. It has a defined end state. It requires no one to give anything up. Its output is a deliverable that can be presented, which makes it reportable as progress.

Retirement has none of those properties. It requires somebody to accept a loss. It has no natural completion point. And its output is an absence, which is difficult to present to a steering committee.

So programs drift toward the phase that produces artifacts, and the artifact becomes the outcome. Nobody decides this. It is the path of least resistance for a team being asked monthly what they have to show.

Four things that actually stop a retirement

The obstacles are consistent, and none of them is technical.

Nobody can prove nothing depends on it.

You can establish that a system is used. Establishing that it is not depended upon is a much harder claim, because dependencies hide in scheduled jobs, extracts, spreadsheets on somebody’s desktop, and the quarterly process that runs once and matters enormously. The burden of proof sits on the person proposing removal, and it is a burden nobody can discharge with confidence. So the safe answer is always to leave it running.

The savings do not accrue to anyone in the room.

Retiring an application saves license and infrastructure cost, usually against a central budget. The work is done by a team with its own priorities, and the risk of getting it wrong lands on the business unit that used it. Cost falls locally, benefit lands centrally. That is a straightforward incentive problem and it is rarely addressed, because addressing it means moving money.

The last users are the most powerful ones.

Application usage is not evenly distributed. A system with twelve remaining users is frequently retained because two of them are senior enough that nobody wants the conversation. This is almost never stated in the program documentation, where it appears as a scoping decision.

The data has to go somewhere.

Most retirements fail on retention rather than on function. The application is replaceable; the seven years of records inside it are not, and the receiving system does not have a place for them. Archiving is unglamorous, expensive, and usually discovered late — at which point the program quietly reclassifies the system as strategic.

What distinguishes the ones that work

Three characteristics, and the first is the one most programs get backwards.

They start with retirement, not with counting. A small number of systems are identified as candidates and taken all the way through to decommission, including the archive. This produces a working path before it produces a complete picture, and it surfaces the retention problem in month one instead of month nine.

They fund the decommission separately from the transformation. A retirement that has to compete with feature delivery for the same team’s attention loses every time, because features have sponsors and retirements have accountants.

They measure decommissions, not coverage. The metric is systems switched off this quarter. Not applications cataloged, not percentage of estate assessed, not rationalization roadmap completeness — all of which can rise indefinitely while the estate stays exactly the same size.

How many did you switch off?

An inventory is a prerequisite for rationalization in roughly the way a map is a prerequisite for walking somewhere. Useful, and not the thing.

If a program has been running for six months and its reportable achievement is the completeness of its catalog, it has already failed and has not noticed. The question worth asking at the next steering meeting is not how much of the estate has been assessed. It is how many systems were switched off last quarter, and if the answer is none, what specifically stopped each one.

Those answers will be the four above, in some order. All four are solvable, and none of them is solved by more discovery.

This piece is an analysis of recurring program failure patterns rather than a report of specific research. It cites no studies and names no organizations.