How would you decide which technologies in an estate need attention first?

What is being tested

Whether you prioritise by risk and exposure rather than by how outdated something feels.

The prioritisation

1. Past end of support, in a critical or internet-facing system. Security exposure that cannot be remediated — no patches exist. This is the top of the list without further analysis, and it is frequently what blocks a compliance certification.

2. Approaching end of support with a long migration path. A database version losing support in eighteen months, where migration takes twelve. The deadline is closer than it appears, and these are the ones missed because the date looks distant.

3. Skills evaporating. A technology whose expertise is retiring from the workforce, or where the organisation has one person who knows it. An operational risk regardless of technical merit, and it worsens silently.

4. Blocking a business capability. A technology constraint making something the business needs uneconomic or impossible.

5. Disproportionate operational cost. Something consuming support effort out of proportion to its value.

6. Merely old but supported, stable and adequate. Bottom of the list. Age is not a defect, and modernising a working, supported, low-change component is frequently the least valuable work available.

What to maintain to make this answerable

A technology lifecycle register: for each significant technology, the current version, the supported-until date, the adoption stage, and who owns the upgrade path. Reviewed on a cadence.

Adoption stages — adopt, trial, contain, retire — with the same discipline as the application portfolio, and for the same reason.

Without this register the exposure is discovered during an audit or an incident, which is the expensive way.

The natural decision points

Licence renewals, hardware refresh, vendor end-of-life announcements and major upgrades are the moments when change is already being considered and budget is already in the conversation. Aligning modernisation to them is far easier than creating a separate case.

The standards question underneath

Every technology consumes a share of a finite capacity for operational novelty — expertise, patching, monitoring, someone available at 3am. Reducing variety is genuinely valuable.

But standards need a waiver path. Standards without exceptions are broken quietly rather than formally, and invisible exceptions are worse than granted ones, because you lose the ability to see and support what is actually running.

What a strong answer adds

That a paved road makes the standard the easiest choice, so compliance follows from convenience rather than from enforcement — the only form that survives deadline pressure.