An enterprise has 900 applications, many overlapping. How do you decide what to keep, consolidate, replace or decommission — and why do rationalisation programmes usually stall?

Assess on two axes, not one

Business value — how important is what this application does, how many users, what revenue or risk does it support, is the capability duplicated elsewhere.

Technical health — supportability, security posture, cost to run, availability of skills, integration burden, and whether it can accept change at all.

The quadrants give the disposition:

• High value, healthy → invest.
• High value, unhealthy → modernise, and this is where the effort belongs. These are the applications that will cause an outage or a breach.
• Low value, healthy → leave alone. Cheap and working is a good state, and touching it is a cost with no return.
• Low value, unhealthy → decommission, which is where the savings are.

The data required, and the honest difficulty of getting it

• Actual usage, from logs and authentication records rather than from what owners believe. A large fraction of applications in a 900-application estate have essentially no users, and the owners do not know.
• Total cost including people, not just infrastructure — licences, support contracts, the fraction of a team maintaining it.
• Integration dependencies, which are the actual constraint on decommissioning and are almost always underestimated. The unknown consumer is what stops the shutdown.
• Data retention obligations, which frequently mean the data must survive the application.
• Business ownership, which is often unclear and must be established before anything can be decided.

Why programmes stall

• Decommissioning is nobody's priority. It produces no feature, and the savings accrue centrally while the effort falls locally. Without central funding and an explicit mandate, it does not happen.
• The unknown consumer. Turning something off is risky because nobody is certain who uses it — which is solved by the dark launch approach: turn it off temporarily, see who complains, then turn it off permanently. Blocking access for a period is far more informative than any dependency analysis.
• Data retention obligations treated as a reason to keep the application, when the requirement is to keep the data — exporting it to archival storage removes the application while satisfying the obligation, and this distinction unlocks a large fraction of a typical estate.
• Consolidation projects that never finish, leaving both the old and new systems running — which is worse than either, and is the single most common outcome.
• Boiling the ocean: a two-year programme to rationalise everything, which loses sponsorship before delivering.

What works

• Sequence by savings and risk, starting with the low-value unhealthy quadrant where the case is easiest and the win is fastest — early demonstrated savings fund the political capital for the harder work.
• A firm rule that consolidation includes decommissioning the old system, with a date, in the same funded project. Migration without shutdown is not consolidation.
• Time-boxed increments with visible outcomes.
• Central funding for decommissioning specifically, since the beneficiary is the organisation.
• A gate on new applications, or the estate regrows faster than it is reduced — rationalisation without intake control is a treadmill.
• Archive-and-shutdown as a standard, tooled path, so the common case is cheap.