Retire-First Portfolio Bias

Modernisation programmes default to the most architecturally interesting option. Refactoring is more satisfying to propose than "we will leave it alone" or "we will switch it off", and "we will fix it properly" is easier to justify in a document than either.

The bias that produces better outcomes is the opposite: assign the cheapest option that satisfies the business driver, and require a written justification for anything beyond it.

Why it matters

Most portfolios then resolve into a large number of retire and retain decisions, a moderate number of replatforms, and a small number of genuine rearchitectures. That allocation is dramatically better than treating every system as a modernisation project, because it concentrates the expensive effort where it changes something.

Retire is the highest-return option and the most often skipped, because switching something off requires a conversation with whoever still uses it — while leaving it running requires no conversation at all.

Implementation patterns

• Start from the business driver, not the technical condition. A datacentre exit with a deadline argues for rehosting almost everything; a cost problem argues for replatform and retire; a capability gap argues for refactoring only the components that block it.
• Retain deliberately and say so. A system that is unpleasant, works and is cheap to run does not need fixing, and stating that protects capacity for what does.
• Prove disuse with telemetry before retiring, since asking who uses something reliably misses the report someone built and the job a departed engineer scheduled.
• Turn off before deleting, so the irreversible step becomes reversible and the last consumers surface immediately.
• Count retirement in the programme's success criteria, or the old systems remain and the return is never realised.
• Include shadow systems — a spreadsheet a business process depends on is part of the portfolio and is usually the highest-risk item, having no owner and no backup.

Industry example

Fast-growing B2B platforms such as Udaan and Moglix accumulate internal systems quickly, and their portfolios contain a long tail of applications built for a market, a partner or a process that has since changed. Assessing that tail honestly usually finds that a substantial proportion can be retired outright — which is the cheapest available improvement and the one that removes cost, risk and cognitive load permanently.

Failure scenarios

• Refactor chosen where replatform or retire would do, consuming the budget.
• Rehosting everything on the theory that improvement follows, which it usually does not.
• Assessment producing a document rather than decisions with owners and dates.
• Retirement deferred indefinitely because it has no visible benefit.
• Retain treated as failure, so capacity is spent on systems that did not need it.

Trade-offs

The cheapest sufficient option leaves systems in a state that will need attention again later, and a portfolio managed this way accumulates deferred work rather than resolving it.

That is the correct trade when the deferred work is cheap to defer — a retained system that is stable and inexpensive costs almost nothing to leave — and the wrong one when deferral compounds, as with an unsupported runtime that becomes a compliance finding. The justification requirement exists precisely to catch that second case.

Interview question

"You have forty internal applications and a modernisation budget. Walk me through how you would allocate it, and tell me roughly what proportion you would expect to end up in each category."