An organisation's technology choices from five years ago now constrain its options. How should technology lifecycle be managed rather than discovered?

The failure being described

Technology decisions have a lifespan and no expiry date is set. A datastore chosen for a workload that has since changed, a framework whose community moved on, a version that is now unsupported — each was correct when chosen and none was reviewed.

The consequence compounds: an unsupported version cannot receive security patches, which becomes a compliance finding, which forces an upgrade under time pressure across several major versions at once.

What managing it looks like

• A currency policy: how far behind supported versions the organisation permits itself to be, per component, with an owner. The policy matters less than having one, because it converts an unbounded drift into a bounded one.
• Continuous small upgrades rather than periodic large ones. The cost of upgrading is superlinear in the number of versions skipped, and a team that upgrades quarterly does less total work than one that upgrades every three years.
• Automated dependency updates with good test coverage, which makes the continuous approach affordable.
• A review trigger on every significant technology decision — a date, or a condition such as "revisit when our write volume exceeds X" — recorded in the decision record.
• An exit plan for anything with a vendor, kept current enough to be actionable and rehearsed for the components where concentration risk is material.

The organisational obstacle

Upgrade work loses every individual comparison against feature work, because its value is diffuse and its sponsor is nobody. The aggregate outcome — an estate that is years behind — is a decision nobody made.

The mitigation is a protected allocation rather than per-item negotiation, since each comparison will be lost individually.

The specific pattern to watch

A component that only one person understands. That is a lifecycle risk independent of the technology's own currency, and it usually becomes visible when that person leaves rather than through any review.

Rotating ownership, documenting the decisions and reasoning, and ensuring at least two people can operate anything critical is lifecycle management applied to knowledge rather than to software — and it is the half that is almost never planned.