An estate has 300 applications and the organisation cannot support them all. How do you decide what to retire?
Show the full answer Hide the answer
What is being tested
Whether you use evidence rather than opinion, and whether you know why retirement fails organisationally rather than technically.
The assessment
Two axes: business value and technical health.
| Value | Health | Action |
|---|---|---|
| High | High | Invest — keep it healthy |
| High | Low | Remediate or replace — the urgent quadrant |
| Low | High | Maintain cheaply; resist modernising it |
| Low | Low | Retire — the largest available saving |
Assessing honestly, which is the hard part
Self-assessed health is always amber. Use evidence: incident count, change lead time, patch currency, open vulnerabilities, and — the most revealing single indicator — how many people are willing to work on it.
Self-declared value is always critical. Use evidence too: actual usage data frequently reveals that an application everyone described as essential has forty users, three of whom are its own support team.
That measurement is usually the single most productive step in a rationalisation exercise, and it is routinely skipped in favour of interviews.
Why retirement is the hardest thing to make happen
Nobody is promoted for switching something off. There is no launch, no feature, and a small risk of breaking something. So applications accumulate, each costing licences, infrastructure, patching, security review and a share of attention, indefinitely.
Making it happen requires:
- A named owner for the retirement, with time allocated.
- Consumer identification from usage data, not assumptions — this is where the real work is.
- A migration path for the consumers who remain.
- Explicit budget for decommissioning, or it competes with features and loses every time.
- "Applications retired" tracked as a metric, with the same visibility as applications delivered.
The sequencing
Start with the ones that are low value, low health and have no consumers. They are the cheapest to remove and they build the credibility needed for the harder cases.
Then the low-value applications with few consumers, which need a migration path but a small one.
Leave the high-value, low-health quadrant for last as retirements — those are remediation or replacement programmes, not retirements, and conflating them is how a rationalisation stalls.
The failure to avoid
A rationalisation that consolidates onto the wrong survivor, because the decision was made on system quality rather than on capability fit. The healthier system may support the wrong capability model, and migrating onto it costs more than remediating the other.
What a strong answer adds
That the assessment must be followed by funded action within the same planning cycle. An assessment producing a report and no change is the most common outcome, and it discredits the next attempt.