How to Manage Technical Debt in Legacy Software

I was a CTO at a company with a LOT of technical debt. Here's how I handled it. 1. I found someone in the org (non-exec) who cared about the issue and was organized. 2. We created a framework to rank our tech debt & built a common mini "language" to talk about it easily. 3. Next we documented the entire tech ecosystem & applied the framework to categorize it all. 4. We met with business stakeholders like Product & Sales to add their perspective into the ranking. 5. We grouped the tech debt into a) never touch, b) fix ASAP and c) fix incrementally. 6. We calculated the potential ROI on each item to help acquire funding to fix it. (This was difficult). 7. We built a plan for remediation and integrated the plan into the roadmap. 8. We created a tracking / monitoring best practice specifically for the tech debt remediation work. 9. We were pretty hardcore about reporting the ROI up to the CEO on all the tech debt fix work. 10. After a while of doing this tech debt remediation got baked into our organization. What's the big lesson? Anything can be done in an org if its important enough, you focus on it and you work hard to achieve it. Interesting in more content like this? Sign up for my free newsletter at https://buff.ly/4ccyrM0. #TechLeadership #softwaredevelopment #CTO

𝗧𝗵𝗲 𝗦𝗲𝗰𝗿𝗲𝘁 𝗞𝗶𝗹𝗹𝗲𝗿 𝗜𝗻𝘀𝗶𝗱𝗲 𝗬𝗼𝘂𝗿 𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲: 𝗛𝗶𝗱𝗱𝗲𝗻 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 Most teams feel technical debt. Very few teams can see it early enough to act. Mike Godfrey shares how loveholidays uses static analysis (CodeScene) as an early-warning system for technical debt, not as vanity metrics. What I like about this: it’s basically cybernetics for software delivery: sensors → signals → feedback → control actions. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗲 “𝘀𝗲𝗻𝘀𝗼𝗿𝘀” 𝗿𝗲𝘃𝗲𝗮𝗹: - Hotspots: where change and effort concentrate (your real pressure points) - Change coupling: files that keep changing together → hidden dependencies - Knowledge distribution (bus factor): where knowledge is lost or stuck in "islands" - Team–code alignment (Conway’s Law): overlap often signals unclear ownership 𝗪𝗵𝗲𝗿𝗲 𝗶𝘁 𝗴𝗲𝘁𝘀 𝗿𝗲𝗮𝗹: They integrate it into the workflow with branch analysis, so PRs can be flagged/blocked when code health declines. That’s a closed feedback loop, not a dashboard. If you want sustainable speed, this is the game: Make technical debt observable, actionable, and governed by clear guardrails. Especially now in the age of AI. #TechnicalDebt #StaticAnalysis #CodeHealth #PlatformEngineering #DevOps

𝐖𝐡𝐲 𝐈𝐬 𝐈𝐭 𝐒𝐨 𝐇𝐚𝐫𝐝 𝐭𝐨 𝐆𝐞𝐭 𝐑𝐢𝐝 𝐨𝐟 𝐓𝐞𝐜𝐡𝐧𝐨𝐥𝐨𝐠𝐲 𝐃𝐞𝐛𝐭 𝐢𝐧 𝐎𝐫𝐠𝐚𝐧𝐢𝐳𝐚𝐭𝐢𝐨𝐧𝐬? Ever wonder why it's tough for companies to move away from outdated technology? It’s like trying to upgrade an old car piece by piece instead of buying a new one — both time-consuming and complex. Let’s break down why clearing tech debt is a challenge and how we can tackle it: 𝐖𝐡𝐚𝐭’𝐬 𝐇𝐨𝐥𝐝𝐢𝐧𝐠 𝐔𝐬 𝐁𝐚𝐜𝐤? 📌𝐂𝐨𝐬𝐭 𝐂𝐨𝐧𝐜𝐞𝐫𝐧𝐬: Upgrading technology can be expensive. Often, companies need to prioritize immediate needs over long-term improvements, pushing tech updates to the back burner. 📌𝐃𝐨𝐰𝐧𝐭𝐢𝐦𝐞 𝐚𝐧𝐝 𝐃𝐢𝐬𝐫𝐮𝐩𝐭𝐢𝐨𝐧: Fear of interrupting daily operations can delay upgrades. Nobody wants to halt production or services just to update systems. 📌𝐂𝐨𝐦𝐩𝐥𝐞𝐱 𝐒𝐲𝐬𝐭𝐞𝐦𝐬: Over time, systems become deeply integrated. Changing one part might affect many others, making updates a complex puzzle. 📌𝐋𝐚𝐜𝐤 𝐨𝐟 𝐄𝐱𝐩𝐞𝐫𝐭𝐢𝐬𝐞: Sometimes, there just aren’t enough skilled hands to manage and implement new technologies smoothly. 𝐁𝐫𝐞𝐚𝐤𝐢𝐧𝐠 𝐅𝐫𝐞𝐞 𝐟𝐫𝐨𝐦 𝐎𝐥𝐝 𝐓𝐞𝐜𝐡: 📌𝐒𝐭𝐫𝐚𝐭𝐞𝐠𝐢𝐜 𝐏𝐥𝐚𝐧𝐧𝐢𝐧𝐠: Address tech debt in business plans. Prioritize updates that offer the most value and plan them in stages to manage costs and disruption. 📌𝐈𝐧𝐯𝐞𝐬𝐭 𝐢𝐧 𝐓𝐫𝐚𝐢𝐧𝐢𝐧𝐠: Building a skilled team is essential. Invest in training your staff to handle new technologies or hire talent with the necessary expertise. 📌𝐄𝐦𝐛𝐫𝐚𝐜𝐞 𝐈𝐧𝐜𝐫𝐞𝐦𝐞𝐧𝐭𝐚𝐥 𝐂𝐡𝐚𝐧𝐠𝐞𝐬:  Instead of one massive overhaul, make smaller, manageable updates. This reduces risk and spreads out the cost over time. 📌𝐋𝐞𝐯𝐞𝐫𝐚𝐠𝐞 𝐄𝐱𝐭𝐞𝐫𝐧𝐚𝐥 𝐇𝐞𝐥𝐩: Sometimes bringing in consultants or using managed services can offer the expertise and extra hands needed to tackle big updates. 𝑮𝒆𝒕𝒕𝒊𝒏𝒈 𝒓𝒊𝒅 𝒐𝒇 𝒕𝒆𝒄𝒉𝒏𝒐𝒍𝒐𝒈𝒚 𝒅𝒆𝒃𝒕 𝒊𝒔𝒏’𝒕 𝒋𝒖𝒔𝒕 𝒂𝒃𝒐𝒖𝒕 𝒖𝒑𝒈𝒓𝒂𝒅𝒊𝒏𝒈 𝒐𝒍𝒅 𝒔𝒚𝒔𝒕𝒆𝒎𝒔; 𝒊𝒕’𝒔 𝒂𝒃𝒐𝒖𝒕 𝒎𝒂𝒌𝒊𝒏𝒈 𝒔𝒕𝒓𝒂𝒕𝒆𝒈𝒊𝒄 𝒅𝒆𝒄𝒊𝒔𝒊𝒐𝒏𝒔 𝒕𝒉𝒂𝒕 𝒂𝒍𝒊𝒈𝒏 𝒘𝒊𝒕𝒉 𝒍𝒐𝒏𝒈-𝒕𝒆𝒓𝒎 𝒃𝒖𝒔𝒊𝒏𝒆𝒔𝒔 𝒈𝒐𝒂𝒍𝒔. 𝑰𝒕’𝒔 𝒕𝒐𝒖𝒈𝒉 𝒃𝒖𝒕 𝒏𝒐𝒕 𝒊𝒎𝒑𝒐𝒔𝒔𝒊𝒃𝒍𝒆 𝒘𝒊𝒕𝒉 𝒕𝒉𝒆 𝒓𝒊𝒈𝒉𝒕 𝒂𝒑𝒑𝒓𝒐𝒂𝒄𝒉 𝒂𝒏𝒅 𝒎𝒊𝒏𝒅𝒔𝒆𝒕. Ready to tackle tech debt in your organization? What’s your first step going to be? Let’s discuss strategies and successes below!

Do your engineers have the power to pay off technical debt? I go to a lot of production incident retrospectives. That's been a major part of my role in my last 4 jobs, including at Google. After some number of incidents, you stop being surprised at anything. There are a finite number of patterns for how systems fail and they repeat again and again. A ton of incidents are caused or exacerbated, at some level, by "technical debt." A deficiency in testing or observability, for instance, contributes to probably 90% of incidents I've ever encountered. A really simple response is "engineers should just write more tests." But I find that's a really reductive view. Some fraction of the time, the retrospective reveals some sloppy engineering: "we wanted to move fast and we didn't write tests because we thought that would make us move less fast." But there's another pattern I see pretty frequently: "We didn't write tests because there is literally no way to write a test that would catch this issue at our company today." Catching the bug would have required an integration test environment shared between multiple teams. Or negotiating a staging environment with a key vendor. Or a load test environment that duplicates a sizable fraction of your team's infrastructure. It's not just a skills issue; the test cannot be written today. This is an insidious type of technical debt, because it is not something that can be fixed with the simple application of engineering hours. It's not, "the engineers should be less sloppy," it's "you need to buy the engineers better tools." These issues can only be fixed with a tangible investment by company leaders. Leaders have to green-light the purchasing of additional servers (or public cloud usage) to launch and maintain a testing environment. They need to fund a QA team to operate a complex test environment or orchestrate manual validations. They can sign the contracts for better tools or renegotiate vendor relationships to require support for staging environments. When I worked in payment processing, we had a complex QA environment where we could simulate the sorts of failures that arise in the real world: expired credit cards, cards declined for insufficient funds, accounts suspended for suspected criminal activity. It takes a substantial amount of infrastructure to be able to test these non-happy-path cases all the way down to the level of your banking vendors. It's not something an engineer can just develop when they want to pay down the team's technical debt. This is why leaders need to pay attention to the team's cries about technical debt. Systemic problems call for systemic solutions, and when the solution involves capex or headcount, engineering teams can rarely do the needful alone.

After years as a Team Lead at Google, I can confidently say: 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗰𝗼𝗱𝗶𝗻𝗴 𝗽𝗿𝗼𝗯𝗹𝗲𝗺. 𝗜𝘁’𝘀 𝗮 𝗿𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗮𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗯𝗹𝗲𝗺. The problem isn't the code quality; it's the 𝗹𝗶𝗲 that leadership accepts when prioritizing 100% features and 0% maintenance. If you lead a team, stop thinking about debt as 'bad code' and start thinking about it as a 𝗵𝗶𝗱𝗱𝗲𝗻 𝗿𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝘁𝗮𝘅 on every feature you ship. Here are the three unexpected costs of "quick wins" that eventually crush teams: 𝗧𝗵𝗲 "𝗖𝗼𝗴𝗻𝗶𝘁𝗶𝘃𝗲 𝗟𝗼𝗮𝗱" 𝗧𝗮𝘅: Every piece of ignored debt adds complexity. New engineers spend 2x longer onboarding. Existing engineers spend 3x longer debugging. Your velocity looks good on the spreadsheet but is silently being suffocated by mental friction. 𝗧𝗵𝗲 "𝗔𝘁𝘁𝗿𝗶𝘁𝗶𝗼𝗻" 𝗧𝗮𝘅: Your best, most detail-oriented engineers leave first. They leave because they came to solve challenging new problems, not fight the same old mess inherited from a rushed deadline two years ago. Debt is a talent retention killer. 𝗧𝗵𝗲 "𝗘𝗺𝗲𝗿𝗴𝗲𝗻𝗰𝘆 𝗢𝗻𝗹𝘆" 𝗧𝗮𝘅: By only tackling debt during an immediate, catastrophic failure (the outage), you guarantee two things: 1) The work is done under maximum stress, increasing risk, and 2) You solidify the negative perception that maintenance work is only necessary when the business is actively losing money. 𝗧𝗵𝗲 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻: As a leader, you must mandate and protect a 20% 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗛𝗲𝗮𝗹𝘁𝗵 𝗕𝘂𝗱𝗴𝗲𝘁 every sprint. If the business won't budget 20% for maintenance, they are implicitly budgeting for 100% of future chaos. #TechnicalDebt #SoftwareEngineering #EngineeringLeadership #ProductManagement

The biggest threat to innovation? It’s not lack of talent. It’s not lack of funding. It’s technical debt. The reality: Every time an employee waits for a slow system to load, that’s lost productivity. Every time a business relies on outdated tools, that’s missed revenue. Every time IT has to patch instead of innovate, that’s stalled transformation. And the worst part? The longer you ignore it, the more expensive it becomes. How it happens: Enterprise leaders unknowingly accumulate technical debt when they: Delay critical system upgrades to “save costs” Patch legacy systems instead of modernizing them Ignore architectural debt while chasing short-term wins The result? A fragile, inefficient IT landscape that increases risk and makes transformation exponentially harder. The fix: ✅ Treat technical debt like financial debt → Proactively measure, manage, and reduce it. ✅ Invest in enterprise architecture → A strategic roadmap reduces redundant systems and optimizes total cost of ownership (TCO). ✅ Align IT and business strategy → Every IT dollar should drive measurable business outcomes. Real-world impact: At one of the global manufacturing companies I worked with, we faced overwhelming technical debt—multiple ERP systems, siloed applications, and legacy infrastructure slowing down operations. By implementing an enterprise-wide modernization strategy, we: ✔ Cut IT costs by 34% ✔ Eliminated redundant applications ✔ Freed up resources for true innovation Because technical debt isn’t just an IT challenge—it’s a business priority. The question isn’t whether you have technical debt—it’s whether you’re actively managing it. The sooner you address it, the less it will cost you. P.S. What’s the biggest challenge in addressing technical debt—cost, leadership buy-in, or execution? Drop your thoughts in the comments. And if you need help tackling it, let’s connect.

A lot of people say that AI agents don't work well on large legacy codebases. That's false. Over the last eight months, I've been successfully using AI agents to clean up massive portions of legacy tech debt in a very large Java and Kotlin codebase that's over 10 years old and used by millions of people. It works. You just have to set up the prompt and engineer the context management correctly. The prompts I use have been iterated on for quite a while. I create one, test it out, find some edge cases I missed, undo the changes, and try again. I do this while performing other work, so it's done in parallel. Ultimately, the prompt typically ends up anywhere from around 800 words to over 2,000 words long. It's a basic full-on manual of how to perform some type of tech debt migration. This has been further expanded by other skills that I have developed. The agent will call into them when it needs to perform certain actions or determines that it is not ready to perform a particular operation because of another dependency. So they maintain their own context window. Done correctly and at the right level, you will have presented the agent with a set of instructions that is a full decision matrix. This covers how to successfully dissect, update, and migrate from one technology to another—all with full guardrails, verification, and more. The majority of pull requests I have opened with these agents are nearly impossible to identify as having been written by an agent. They follow proper standards, protocols, and implementation details that our team has dictated. This is enforced through deterministic methods such as linting, testing, verification, and sub-agents that do additional verification before completing. Finally, when the agent is complete and everything is working, I will open the pull request in a draft state and manually review it there. Once I'm happy with it, I'll transition it to a pull request that's ready to be reviewed. Then, additional AI agent reviewers will perform another set of analysis on top of that, along with a human reviewer.

For years, my teams have been shackled by decades of legacy tech debt. The core systems built for scale (like IBM big iron) now present the biggest obstacles to innovation and create a crippling skills gap. But that leads to an exciting opportunity as we are finding that AI-assisted modernization is the key to finally getting unstuck. I was initially skeptical as I had been down a path a decade prior where tech modernization would address what was slowing us down with these legacy systems, but to no avail. At the same time, I had many doubts about how AI on our mission critical platforms would perform given the high risk of errors and hallucinations. So we started with governance, robust process and creating guardrails and that is where the aha moment came. Simply we acknowledged that in order to be successful, we must address the governance gap first to minimize the high risk of breaking things in systems. For banks and credit unions, these are systems where people buy groceries and pay for childcare. AI coding assistants are poised to be game-changers. I would submit we can expect them to help document legacy applications, rewrite old code, and automate testing. This dramatically accelerates the pace of modernization, overcoming the traditional barriers of mainframe skills gaps and complex integration. Like most, I am sure most are facing tens of millions of lines of code? My advice is always not to attempt to boil the ocean. Instead focusing on the highest-value modules first and ensures upgrades occur in a secure sandbox before hitting production. This disciplined approach minimizes risk while maximizing immediate ROI. Legacy tech upgrades often stall or fail initially. Success demands the kind of courageous, disciplined leadership that prioritizes process and risk mitigation before chasing speed. AI is the tool, but governance is the strategy. #CIO #CTO #DigitalTransformation #TechDebt #AIGovernance #Fintech #LegacyModernization #Leadership

You’re an engineering leader, a staff+ engineer, or a product owner who sees the cost of technical debt every day. But when you try to advocate for time to fix it, execs either nod vaguely or change the subject. You’re not wrong—you’re just not being heard. Here’s why that happens: When you say "tech debt," they hear "not urgent." When you say "refactor," they hear "money pit." When you say "architecture," they hear "someone else’s problem." But the reality is: Tech debt slows down your ability to ship new features. It increases the risk of outages or missed SLAs. It silently drives away your best engineers. So how do you make them care? I coach engineering and product leaders on how to frame technical priorities in business language—so they get the time, resources, and executive backing they need. Here’s the approach: Tie tech debt to business risk or cost: "This feature now takes 3x longer to ship because of X." Use executive language: Talk time-to-market, reliability, developer retention—not code quality. Frame it as an investment: "Fixing this sets us up for velocity in Q3." Make tradeoffs visible: "If we don’t fix this now, we’ll miss Y opportunity." Track real pain: Show data on cycle time, error rates, or turnover. Don’t wait for permission. If your leadership still sees tech debt as an engineering problem, it’s time to change the story you’re telling. This is where I come in. I help technical leaders communicate with power—bridging the gap between strategy and systems. Whether through coaching or fractional partnership, let’s get your org moving faster and smarter. #technicalleadership #engineeringmanagement #productstrategy #executivecommunication #startupgrowth

Never call a task "Pay down tech debt". Don't call it "Refactor the flux capacitor" either. → Use a business justification, e.g.: 1. "Reduce dashboard load time to <1s" 2. "Reduce sign-up error rate to below X%" 3. "Handle more than X payments per second" These ones have also been known to work: 4. "Avoid downtime when XYZ's old API stops working" 5. "Reduce incidents due to module X instability" 6. "Reduce the cost of each future change"  7. "Decrease ongoing maintenance costs" 8. "Mitigate engineer attrition rate" 😉 If you can't find a convincing business justification, are you really sure it's warranted? If you're feeling overwhelmed by tech debt, be pragmatic. Ask yourself: 1. What 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 problems it is causing? 2. Are these 𝗰𝘂𝗿𝗿𝗲𝗻𝘁 problems, or 𝗳𝘂𝘁𝘂𝗿𝗲 risks? You'll always carry a conscious amount of tech debt.  That can be OK, as long as you track it and evaluate the risks. Make a plan that deals with it gradually and consistently over time, without having to bring other development to a standstill.