Your competitor shipped a feature in two weeks that your team needs four months to replicate. A PE firm’s due diligence team is asking hard questions you can’t answer cleanly. Your best engineer just put in her notice, in part because she’s tired of maintaining legacy code that hasn’t been meaningfully updated since 2016.
None of these are hypotheticals. They’re the predictable consequences of legacy systems that have been left alone too long.
Legacy code has a way of becoming invisible. Systems run in the background, processing transactions, storing data, keeping the lights on. And because they work, no one talks about them. Until they don’t work. Or until the business needs to move, and the architecture won’t let it.
The problem isn’t that legacy systems exist. Every company with any history has them. The problem is that most organizations dramatically underestimate what they’re actually costing: not just in infrastructure bills or the occasional outage, but in the slow, compounding drag on every part of the business.
Legacy Code: The Cost Is Bigger Than Your Tech Budget
When engineering leaders think about the cost of legacy systems, they tend to think in terms of maintenance: the hours spent patching old code, the on-call rotations, the vendor support contracts for software nobody updated since 2014. Those costs are real, but they’re the easy ones to see.
The harder costs don’t show up on an engineering budget line.
Developer velocity loss is one of the most significant. Engineers working in legacy codebases spend a disproportionate share of their time reading and deciphering code rather than writing it. Every new feature requires navigating years of undocumented decisions, workarounds, and tribal knowledge. Sprint velocity drops. Release cycles stretch. The business, which needs to move fast, doesn’t.
A global luxury travel company experienced this firsthand. Constrained by a decade-old codebase, its internal teams were struggling to keep pace with product demands. Not because they lacked talent, but because the architecture wouldn’t let them move. After modernizing with a new CI/CD pipeline, automated testing, and a migration to .NET 6 on Linux, the company doubled its feature delivery velocity. The constraint wasn’t ambition or headcount. It was the system itself.
Talent retention compounds the problem. Strong engineers, the ones you most want to keep, don’t want to spend their careers maintaining systems built on outdated stacks. When competitors are offering greenfield work and modern tooling, legacy-heavy environments become a recruiting liability. You end up losing your best people and finding it harder to attract replacements.
Incident rate and operational risk grow over time. Legacy systems accumulate fragility in ways that are hard to see until something breaks. Integrations built as one-off solutions become load-bearing walls. When failure happens, it’s hard to diagnose and expensive to fix. Every hour of downtime carries a revenue cost, a customer trust cost, and a team morale cost.
Opportunity cost may be the largest category of all. Legacy architecture doesn’t just slow down existing work; it blocks new work entirely. A monolithic billing system that can’t be scaled independently. A data pipeline that can’t support modern analytics. A codebase where AI integration is effectively impossible. The features and capabilities your business needs to grow are often blocked not by ambition or resources, but by architecture.
Accuray, a global leader in radiation oncology systems, ran into exactly this ceiling. Their legacy desktop applications required engineers to physically visit every machine location to push software updates, a model that simply couldn’t scale as the company grew. Beyond the operational burden, the architecture made it impossible to offer the richer data and insights their medical customers needed. Modernizing to a cloud-based, microservices architecture didn’t just reduce operational overhead; it unlocked entirely new product capabilities and cut the software delivery timeline by roughly 50%.
How PE Firms Are Thinking About This
If your company is PE-backed or heading toward a liquidity event, the calculus around legacy code has shifted significantly. Technology due diligence has grown more sophisticated. Acquirers and investors are no longer satisfied with a high-level architecture overview. They want to understand scalability, deployment frequency, test coverage, dependency risk, and the ratio of innovation work to maintenance work on any given engineering team.
Legacy systems that are “working fine” can become valuation risk when a buyer’s technical team starts asking how long it would take to migrate off a deprecated database, or what happens if the one engineer who understands the legacy billing system leaves. These aren’t hypothetical concerns. They’re deal points that affect purchase price, escrow terms, and whether a deal closes at all.
Putting a Number on Technical Debt
Most organizations know they have technical debt. Far fewer have quantified it in business terms. Here’s a simple framework, illustrated with rough numbers to make it concrete.
Velocity drag
Estimate the percentage of engineering time consumed by legacy code maintenance versus net-new work. If you have a 40-person engineering team with a fully-loaded cost of $200K per engineer per year, and 40% of their time goes to legacy maintenance rather than new development, that’s $3.2M annually in productivity cost, before a single line of new code is written.
Incident cost
Track mean time to resolve incidents tied to legacy systems. Multiply by frequency and by the loaded cost of your on-call team, plus any revenue impact from downtime. For a company doing $50M in annual revenue, even two hours of monthly downtime at a conservative 50% revenue attribution adds up quickly, and legacy-related incidents are rarely two-hour events.
Oportunity cost
Identify two or three strategic capabilities your business wants to build. Estimate how much longer they take to deliver in your current architecture versus a modern one. When a leading home services marketplace was constrained by fragmented legacy platforms from years of acquisitions, its payment infrastructure couldn’t support the transaction volume the business needed. After modernization, payment volume grew twentyfold within a year of launch, and an entirely new financing capability was unlocked that hadn’t been possible before.
Add those three numbers together and you’ll usually find a figure that reframes the modernization conversation. It stops being “a large capital expense to fix something that’s working” and starts being “a strategic investment that pays for itself within 12 to 18 months.”
Working Code Is Not the Same as Scalable Code
This distinction matters more than most leaders realize, and it’s worth sitting with.
Legacy systems earn their status by being reliable. They’ve survived years of production use, edge cases, and organizational change. That’s genuinely valuable. A system that processes transactions without errors, that the team understands, that hasn’t gone down in three years: these things have real worth. We’re not dismissing them.
But reliability in the past is not fitness for the future. A monolith that can’t be decomposed into independently scalable services. A database schema designed before real-time analytics was a business requirement. A desktop application that requires on-site visits to update. An API layer that makes AI integration architecturally impossible. Each of these is a system that “works,” and each is a ceiling on what the business can become.
The honest question isn’t whether your legacy systems are working today. It’s whether they can support the business you’re trying to build tomorrow, and at what cost. Sometimes the answer is yes: the modernization math doesn’t pencil out, the systems are stable, and the better investment is elsewhere. That’s a legitimate outcome of a clear-eyed assessment. But most organizations making that call haven’t done the math. They’re defaulting to inertia and calling it a decision.
Modernization isn’t about discarding what works. It’s about understanding the full price of keeping it as-is, and making an honest trade-off with complete information.
What would your team ship if legacy code wasn’t holding it back? Gorilla Logic works with engineering and business leaders to put a real number on technical debt and build a practical path out of it, without disrupting what’s already working.
