In December 2022, the American airline Southwest Airlines canceled nearly 17,000 flights during peak travel season. One of the main reasons was a legacy crew scheduling system that couldn’t automatically handle the massive volume of changes in flight schedules. This forced employees to switch to manual processes, leading to a full-scale collapse.
The consequences were severe: a $140 million fine from the U.S. Department of Transportation and $600 million in passenger compensation. According to a Consortium for Information & Software Quality report, in 2022, the accumulated technical debt in legacy code across U.S. companies was estimated at $1.52 trillion — essentially a “tax on outdated code” that businesses pay every year.
In nearly two decades in the IT industry, I’ve seen many cases where legacy code became a barrier to a company’s growth. Even when the excessive maintenance costs are obvious, business leaders are often reluctant to invest in updates that don’t promise immediate profit. I’d like to share my experience on how technical leaders can convince stakeholders that refactoring is, in fact, an investment.
The hidden cost of delay
CEOs often postpone refactoring. The main reasons are the fear of disrupting stable business processes and the difficulty of assessing ROI. Add to that the scale of expenses — according to McKinsey, modernizing a large system can cost hundreds of millions of dollars and take 5-7 years.
However, delaying refactoring has long-term consequences. Beyond the obvious ones, such as release delays and financial losses, there’s another serious risk — talent retention. According to a Storyblok survey, 73% of developers know colleagues who have quit their jobs due to poor tech stacks.
Another cautionary tale for any business with an IT component is the case of Netscape, once the world’s leading browser in the mid-1990s. Starting with version 4.0, the browser became prone to crashes and instability due to outdated code. Instead of timely refactoring, the Netscape development team opted for a complete rewrite as part of an open-source project. While the code was being rewritten from scratch, the company only released pre-alpha versions. Meanwhile, competitors moved quickly, and by the time the updated Netscape finally launched, Microsoft Internet Explorer had already captured the market.
How to calculate ROI on refactoring
In June this year, the UK software company Cron AI faced several issues: their application suffered from 3-4 second response delays, 45-minute deployments, and legacy code that blocked new features, causing frequent crashes. The Cron AI team decided to remove 30% of the codebase — including dead and duplicated code, outdated adapters, and unused experimental branches. After this, response time dropped to under 500 ms, deployments became twice as fast, and developer productivity increased by 40%.
This case is an example of strategic refactoring, which helps reduce technical debt and adapt a system to new user requirements. It also protects the business from scenarios similar to Southwest Airlines and Netscape.
From my experience, however, cautionary examples and a CTO’s arguments alone are not enough to convince stakeholders. Technical leaders need to demonstrate that refactoring is an investment with a clear ROI, which means speaking in terms of numbers and benefits.
There is a simple formula for calculating ROI: (Benefits – Costs) / Costs × 100%. For instance, if refactoring costs $50k and the annual savings on maintenance and faster development amount to $200k, the ROI would be 300%.
6 arguments beyond ROI
Sometimes, even the numbers are not enough to convince a CEO. My advice: before discussing the need for refactoring with leadership, prepare in advance.
Here’s what can make your arguments more persuasive:
- Calculate the cost of maintaining legacy code. Start with concrete numbers: how many hours the team spends maintaining the outdated system each month, what it costs the company, and how many bugs arise due to technical debt.
- Model the economic impact of refactoring. Explain how refactoring can reduce these costs, supported by successful examples from your experience or industry studies.
- Discuss the risks of ignoring refactoring. Emphasize that legacy code slows down releases, causing the company to lose competitive advantages. Add the staffing risk: outdated tech stacks demotivate teams, increase turnover, and raise developer retention costs.
- Start with a pilot. Refactor one critical or problematic module and showcase the results. This allows you to present measurable metrics to the business and build trust for larger technical initiatives.
- Invite business leaders to bug triage sessions. This lets them see firsthand the scale of legacy code issues and understand that much of the team’s time is spent “putting out fires” instead of building new features.
- Explain AI’s role in modernization. AI can significantly simplify refactoring legacy systems and reduce both budget and time for these projects.
A CTO should be the first to see when it’s time to change course and have the courage to act. Your role is not only to recognize when code needs updating but also to demonstrate to the business that these changes are profitable. Well-prepared data and clear arguments are your most powerful tools.