curiousecurity

Enterprise architecture and security governance, from the board seat

  • Posts
  • About
  • Career
  • Education
  • Contact
  • LinkedIn
  • GitHub
  • Email
You are here: Home / Architecture / The Architecture Board Loves Approving New Systems. It Almost Never Retires the Old Ones.

The Architecture Board Loves Approving New Systems. It Almost Never Retires the Old Ones.

August 7, 2026 by The Architecture Desk

Ask anyone on your architecture board to name the last system the board actually voted to retire, not deprecate in a slide, not flagged “legacy” in a spreadsheet somewhere, but formally decommissioned. Watch them pause. They’ll rattle off every platform evaluation and integration exception from the last year without breaking a sweat, but retirement almost never shows up as its own agenda item. It shows up as a footnote buried in someone else’s proposal, if it shows up at all. That’s not because nobody thinks the old stuff should go away, everybody agrees it should. Every enterprise inventory has a long tail nobody trusts and nobody wants to touch. It’s that retirement almost never gets a sponsor the way new work does.

New Work Has a Champion. Retirement Doesn’t.

A new system shows up with a business case, a budget line, an executive who wants credit for shipping it, and a deadline that forces the board’s hand whether anyone’s ready or not. A decommission has none of that built in, and I mean none of it. Nobody demos an integration you finally managed to turn off. There’s no revenue line attached to it, just a slow, unglamorous discovery phase where someone has to go track down every batch job, every report, every undocumented dependency hanging off the thing before it’s safe to pull the plug. Put a budget owner in front of a choice between funding the next initiative and funding an internal cleanup nobody’s championing, and the initiative wins. Every time. The retirement backlog doesn’t shrink, it compounds, quietly, year over year, and by the time anyone notices it’s a real problem.

The Bill Still Comes Due

Federal IT makes this visible because, unlike most of us, the numbers are public. The Government Accountability Office’s 2025 report on legacy modernization found agencies planned to spend roughly 79 percent of their fiscal year 2025 IT budget just operating and maintaining existing systems, decades-old platforms included, leaving a sliver for anything new or for actually retiring what’s already sitting there. Private enterprises don’t publish that ratio (I wish they did), but anyone who’s sat on an EA board recognizes the shape of it immediately. The maintenance tax on old systems quietly eats the budget that should be funding new capability and cleanup both.

The security side turns that neglect into a number you can’t argue with. CISA’s May 2026 addition to its Known Exploited Vulnerabilities catalog included legacy Windows, Internet Explorer, DirectX, and Adobe issues first identified between 2008 and 2010, and they’re still being actively exploited seventeen years later. Seventeen. Nobody sat in a room and chose to keep running vulnerable software. They ran it because the system underneath was never formally retired, just patched around, wrapped in compensating controls, and left standing because the migration work never once won against whatever was next on the roadmap.

IBM’s 2026 Cost of a Data Breach Report prices out where that catches up with you: the average breach now runs $4.99 million, and on-premises environments, disproportionately where legacy systems live, were breached more often than cloud environments in the same dataset. Every quarter a retirement decision sits unmade is a quarter of exposure carried on top of the direct maintenance spend, and that exposure doesn’t show up on anyone’s dashboard until it’s too late to matter.

Make It a Required Field, Not a Task Force

Nobody on an architecture board is out there arguing against retiring old systems in principle, I’ve never once heard that case made. Retirement loses by default because it never becomes a decision anyone is forced to make. A new system gets scored, gets a business case, and lands on the docket because someone actually needs it approved. A legacy system just keeps running, because shutting it down requires someone to actively start the work, and there’s no natural forcing moment for that, not until a breach, an audit finding, or a vendor end-of-life notice drags the conversation onto someone else’s timeline instead of yours.

A decommissioning initiative or task force won’t fix that, and I used to think it would. It gets funded once, produces a burst of activity everyone feels good about, and the backlog starts refilling the moment the initiative wraps, because the structural gap underneath never actually closed. The fix is making retirement a standing, mandatory part of how new work gets approved, the same discipline I laid out in The Architecture Review Board: Narrow Docket, Small Room, Hard Exceptions, so retirement sits on the docket every cycle instead of surfacing as an occasional special project nobody owns.

  • Every new-system proposal has to name what it replaces or should eventually retire, even if the honest answer is “nothing yet.” A blank answer doesn’t pass silently, it’s a documented decision the board actually looks at and signs off on.
  • Every system in the portfolio carries a sunset status, not just a supported/unsupported tag, so the board can see the retirement backlog as real, sized work instead of a vague sense that “we have some old stuff floating around.”
  • Retirement decisions get the same rigor as build decisions: an owner, a target date, and a documented consequence if that date slips.

None of that holds up if the inventory lives in a spreadsheet or a wiki page nobody’s touched since last year. I run this through LeanIX for the same reason I’ve written about before: a decommission candidate that isn’t mapped in the EAM system of record doesn’t functionally exist to the board, because nothing forces anyone to revisit it. Put sunset status next to cost, ownership, and dependency data in the same tool used for every other architecture decision, and “still running” stops being an acceptable steady state. It becomes a line item someone has to justify every review cycle, the same discipline behind Reuse, Buy, Build: The Order Most Companies Get Backwards, just applied on the way out instead of the way in.

If your board has an agenda template, add one required field to it this week: “what does this proposal let us shut off.” Not optional, not narrative, a field every proposer has to fill in before the board votes, even when the honest answer is nothing yet. Run that for two review cycles and you’ll have an actual, sized retirement backlog, instead of a shared feeling that some old systems are out there somewhere, quietly costing you money and sleep.

Photo by Dean Brierley on Unsplash

Related

Filed Under: Architecture Tagged With: cybersecurity, enterprise-architecture