Technical Debt and Modernization: Building the Portfolio Case

Every technology leader inherits technical debt: aging platforms, brittle integrations, unsupported software, code nobody wants to touch. The engineering team usually knows exactly where it hurts. The hard part is convincing the people who control the budget that fixing it deserves money ahead of new features.

That argument rarely succeeds as a plea to "pay down tech debt." It succeeds when debt is translated into business risk and cost, organized into a portfolio, and presented with clear options and a realistic plan.

This guide covers how to build that case at the portfolio level. It assumes you already know what technical debt is in code and architecture; the focus here is on the decisions executives need to make.

What the metaphor does and does not mean

Ward Cunningham introduced the debt metaphor in a 1992 OOPSLA experience report: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." The point was never that debt is bad. Borrowing can be smart, as long as you know you are doing it and plan to repay.

Martin Fowler's Technical Debt Quadrant (2009) adds a useful distinction between deliberate and inadvertent debt, and between prudent and reckless debt. Prudent, deliberate debt is a considered trade-off to meet a real deadline. Prudent, inadvertent debt is what even good teams discover once they learn what the design ought to have been. Reckless debt, deliberate or not, comes from ignoring good practice.

For executives, the key message is simple: some debt was a reasonable business decision, and some is an unmanaged risk. Your portfolio should make clear which is which.

Translate debt into business terms

Executives do not fund refactoring. They fund lower risk, lower cost, faster change and better resilience. For each significant item, describe its impact in those terms:

• Risk: unsupported software, known vulnerabilities, single points of failure, or systems only one person understands.
• Cost: maintenance contracts, specialist skills, manual workarounds and hosting for systems that could be retired.
• Speed: how long changes take and how often they break things.
• Opportunity: business initiatives that are blocked or slowed by the current platform.

Older systems can consume a large share of budget. The U.S. Government Accountability Office reported in July 2025 that federal agencies "have typically reported spending about 80 percent on operations and maintenance of existing IT." You will need your own figures, but measuring your run-versus-change split is often the most persuasive single number you can bring.

Build an inventory and score it

Start with a list of applications and platforms, not a list of code smells. For each, gather owner, business criticality, users, age, vendor support status, known security issues, run cost and the volume of change requests.

The GAO offers a helpful model. In the same 2025 report, it scored 69 legacy systems submitted by agencies on 16 attributes, "such as age, vendor support, use of legacy programming languages, degree of cybersecurity risk, and operating costs," to identify the 11 most in need of modernization. Eight of those 11 used outdated languages, four had unsupported hardware or software, and seven were operating with known cybersecurity vulnerabilities.

Your scoring can be simpler. For example, a hypothetical midsize insurer might rate each application from one to five on business value, technical condition, security exposure and cost to run, then plot value against condition. The low-condition, high-value systems become the core of the modernization portfolio.

Choose a disposition for each system

Not every system needs a rewrite. AWS's prescriptive guidance on cloud migration describes seven strategies that work as a general vocabulary for disposition decisions, even outside a cloud move:

1. Retire: decommission systems with no remaining business value.
2. Retain: keep as is for now, for example because of dependencies or a recent upgrade.
3. Rehost: move without changes.
4. Relocate: move to another environment without changing the application.
5. Repurchase: replace with a different product, often software as a service.
6. Replatform: move with some optimization, such as a managed database.
7. Refactor or re-architect: redesign significantly.

AWS describes refactoring as the most complex and costly of these and recommends, for large migrations, modernizing after the move where possible. The general lesson applies broadly: reserve the expensive options for systems where the business value justifies them, and look hard at what can simply be retired.

Write a plan with the elements reviewers expect

GAO's report identifies three key elements of a modernization plan: "(1) milestones, (2) a description of the work, and (3) details regarding disposition of the legacy system." Of the 11 critical federal systems it examined, agencies had plans for nine, but only three of those plans included all three elements.

Use those three elements as a minimum, then add what your executives will ask about:

• Cost and funding source, including any period of running old and new systems together.
• Measurable outcomes, such as reduced run cost, retired licenses, fewer incidents or faster change.
• Risks to the plan and how you will reduce them.
• What happens if you do nothing, with a realistic timeline for support ending or failure becoming more likely.

Fund it sustainably

Big-bang modernization programs are hard to approve and hard to deliver. Two patterns are often easier to sustain:

• A standing allocation of team capacity for debt reduction, agreed with business owners and reviewed regularly.
• A small number of funded modernization initiatives, each with its own business case and milestones.

Whatever the model, make the debt visible. A shared register reviewed alongside the project portfolio keeps it from being treated as invisible engineering preference. For writing the individual cases, see our guide to writing an IT strategy the business will actually use.

Key takeaways

• Debt can be a reasonable trade-off; your job is to show which debt is deliberate and which is unmanaged risk.
• Translate debt into risk, cost, speed and opportunity rather than technical language.
• Inventory and score systems on attributes such as age, support, security and cost, as GAO did.
• Choose a disposition for each system, and retire before you rebuild where you can.
• Plans should include milestones, the work, the fate of the legacy system, costs and measurable outcomes.

Sources

• Ward Cunningham, The WyCash Portfolio Management System, OOPSLA '92 Experience Report (1992)
• Martin Fowler, Technical Debt Quadrant (October 14, 2009)
• U.S. Government Accountability Office, Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems, GAO-25-107795 (July 17, 2025)
• Amazon Web Services, About the migration strategies (AWS Prescriptive Guidance)