The risk in your oldest systems

Every institution carries technology it has quietly outgrown: the core that can't be changed without risk, the application no vendor supports anymore, the server nobody wants to touch. Technical debt like this rarely causes a crisis on an ordinary day. It causes one on the worst day, when the system that finally fails is the one you can no longer patch, staff, or replace quickly.

Technical debt is deferred risk, not deferred work

The phrase “technical debt” makes it sound like a productivity problem: work you'll get to later. On a regulated institution's balance of risk, it is something sharper: deferred risk that compounds. End-of-life systems stop receiving security patches, so known vulnerabilities simply accumulate. The people who understood the old platform retire. Documentation rots. Each year the system is harder to change, more expensive to run, and more dangerous to depend on, even as the business quietly builds more on top of it.

Why it's an operational-resilience problem

Supervisors have moved decisively toward operational resilience: the expectation that an institution can keep delivering critical operations through disruption and recover when something breaks. The 2020 interagency paper on sound practices to strengthen operational resilience was the clearest signal of that shift. Legacy and end-of-life technology sits directly athwart the expectation. A critical service running on unsupported software is a single point of failure with no vendor to call, and often no one in-house who fully understands it. Resilience isn't only redundancy; it is whether the thing you depend on can be restored, and whether anyone still knows how.

The trap: invisible until it isn't

Technical debt is easy to defer precisely because it is invisible on a good day. The system still works. The savings from not modernizing show up immediately; the cost shows up later, and somewhere else: in an outage, a failed recovery, a breach through an unpatched component, or an examiner's finding. Boards rarely see it, because it is reported (if at all) as an IT cost line rather than as risk. That is the reframing that matters: end-of-life technology is a risk position the institution is holding, whether or not anyone has named it as one.

Technical debt rarely fails on an ordinary day. It fails on the worst one.

Governing it, not just lamenting it

You can't modernize everything at once, and you shouldn't try. What good governance does is make the debt visible and deliberate:

• Inventory it. Know what's running, what's supported, what's end-of-life, and which critical services depend on each. You cannot manage a risk you can't see.
• Rank by risk, not by age. The oldest system isn't always the most dangerous; the one carrying a critical, customer-facing, or regulated workload is. Prioritize by consequence.
• Fund the plan against appetite. Decide explicitly how much legacy risk you are willing to hold, and fund the modernization of whatever exceeds it, rather than deferring by default.
• Make it board-visible. Report end-of-life exposure as a standing risk measure that trends over time, alongside the other risks the board already governs.

The point

Modernization is usually pitched as an efficiency project. For a regulated institution it is a resilience and risk decision, and, like any risk, the goal isn't zero. It is knowing what you hold, deciding what is tolerable, and retiring the rest before it retires you.