Does a Million Lines of Legacy Code Get in the Way of Making Sales?
Executive Summary & TL;DR
- The real issue isn’t age, it’s changeability: Customers rarely care about legacy code; they care about speed, reliability, and ease of integration.
- Technical debt is a capacity problem: Carrying unmanaged debt drains engineering velocity and capacity away from customer innovation.
- Focus on material constraints: Don’t rewrite for the sake of novelty. Prioritize investment where friction directly affects commercial outcomes, delivery cadence, or operational risk.
Modernisation discussions often begin with a dramatic technical statistic: a million lines of legacy code, an ageing platform, or a critical component that few people fully understand anymore.
The implied conclusion is usually straightforward: this must be hurting sales. The reality is more nuanced.
Customers rarely reject a product because of the age of its codebase or the programming language it was built with. Most buyers never see the underlying technology. What they experience is the outcome of that technology: the quality of the user experience, the ease of integration, the reliability of the service, the pace of innovation, and the confidence they have in the supplier’s ability to meet future needs.
The more useful question is not whether legacy technology exists. The question is whether it is reducing the organisation’s ability to change, adapt, and deliver value.
This paper argues that technical debt should be treated as an investment, capacity, and changeability topic. The purpose is not to eliminate every old component or pursue modernisation for its own sake. It is to identify the constraints that materially affect customer outcomes, business performance, and delivery confidence, then invest where change will create the greatest value.
What Technical Debt Actually Means
Every organisation carries some level of technical debt. That is normal. In many cases, debt is the result of sensible decisions. Teams make deliberate trade-offs to deliver customer value quickly, respond to market opportunities, meet regulatory dates, or learn whether an idea works before making a larger investment.
Technical debt is the accumulated cost of shortcuts, ageing dependencies, workarounds, duplicated solutions, manual processes, inconsistent designs, and decisions that make future change harder than it needs to be. It is not simply old code, and old code is not automatically bad code.
The challenge emerges over time. A shortcut that saved two weeks may require repeated manual work. A customer-specific override may complicate every upgrade. A dependency that was once standard may become unsupported. Individually, each issue may appear manageable. Collectively, they can make delivery slower, riskier, and more expensive.
Some debt is intentional and valuable. The problem begins when the continuing cost of carrying it exceeds the value it originally created, or when nobody can explain that trade-off anymore.
The Real Asset is the Ability to Change
The most valuable capability any product organisation possesses is the ability to change safely and predictably. The faster an organisation can respond to customers, regulation, competitive pressure, and emerging opportunities, the stronger its position becomes.
This is why technical debt is not solely an engineering concern. When it erodes changeability, it affects product strategy, commercial commitments, operations, customer service, and investment choices. It can determine whether an apparently simple enhancement takes days or months, whether a critical upgrade can be planned with confidence, and whether teams spend their capacity creating new value or protecting fragile behaviour.
“The real asset being protected through technical investment is not the codebase itself. It is the organisation’s ability to change.”
What Buyers Actually See
A large codebase is an internal reality. Customers are more likely to notice its consequences. They want to know whether the product meets today’s needs, integrates with their environment, receives regular improvements, supports future requirements, and can be upgraded without disproportionate disruption.
- Does the product feel coherent and easy to use?
- Can it integrate cleanly with existing systems and data flows?
- Can the supplier deliver enhancements within a reasonable timeframe?
- Are releases and upgrades predictable and low risk?
- Does the roadmap feel credible?
- Can the product respond to regulatory and market change?
Very few prospects will ask which programming language powers a module. Many will ask how quickly a new integration can be delivered, how frequently the product is updated, what an upgrade will require, and whether previous commitments have been met.
Legacy becomes commercially relevant when it weakens confidence in the product’s future.
When Legacy Becomes a Business Problem
The strongest argument for reducing technical debt is not that old technology is inherently bad. Mature products can continue to provide excellent value for many years. Stability, proven behaviour, and deep domain capability are often genuine strengths.
The issue arises when the estate creates visible or measurable constraints:
| Technical Constraint | Internal Effect | Customer or Business Impact |
|---|---|---|
| Fragile release process | More manual checking and coordination | Slower delivery and less predictable dates |
| Unsupported dependency | Limited upgrade options & specialist effort | Higher operational and security risk |
| High regression burden | Longer test cycles and delayed feedback | Customers wait longer for enhancements |
| Limited observability | Slower diagnosis and uncertain root cause | Longer incidents and weaker service confidence |
| Complex architecture | Small changes affect many components | Higher cost and lower pace of innovation |
| Manual processes | Repeated effort and human dependency | Higher cost and increased error risk |
| Poor documentation | Knowledge concentration & slower onboarding | Reduced resilience and delivery capacity |
The Hidden Cost is Capacity, Not Optics
One of the biggest misconceptions about legacy systems is that the main problem is appearance. A dated interface can influence perception, particularly during a competitive product demonstration, but visual age is not a reliable measure of underlying value.
The greater cost often sits beneath the surface:
- More effort is required to understand the impact of a change.
- Testing becomes broader and more repetitive.
- Release preparation absorbs specialist time.
- Incidents take longer to investigate.
- Teams avoid valuable changes because the risk feels disproportionate.
- Experiments become too expensive to run.
“Every hour spent overcoming avoidable complexity is an hour that cannot be invested in customers, innovation, or resilience.”
From a product perspective, this is a capacity allocation problem. Technical investment should not be treated as work separate from product strategy. Improving maintainability, testability, observability, and release automation directly increases the organisation’s ability to execute that strategy.
How to Prioritise Technical & Product Debt
Not every debt item deserves immediate attention. The goal is not to eliminate all debt. Prioritisation should connect each material constraint to an outcome using four decision lenses:
- Business Impact: Which customer, commercial, regulatory, or operational outcome is affected?
- Frequency: How often does the constraint slow or disrupt work?
- Cost: What capacity, delay, or recurring expense does it create?
- Risk: What could happen if we do nothing?
Prioritisation Matrix
- High Impact, Lower Effort: Act quickly. Targeted automation, simplification, or key dependency upgrades.
- High Impact, Higher Effort: Strategic investments. Build a staged business case with clear migration planning.
- Lower Impact, Lower Effort: Address opportunistically during adjacent feature work.
- Lower Impact, Higher Effort: Monitor and contain. Avoid heavy investment unless context changes.
Focus on Continuous Improvement, Not Wholesale Rewrites
The word modernisation can create the impression that a massive rewrite is the only response. It rarely is. Rewrites carry substantial delivery, migration, and knowledge risk. Most organisations achieve better results through sustained, incremental work:
- Automate repetitive build, test, and deployment activities.
- Upgrade or replace unsupported dependencies.
- Improve monitoring, tracing, and operational diagnostics.
- Simplify high-friction workflows and remove unused functionality.
- Create consistent API, architecture, and testing guardrails.
- Reduce undocumented customer-specific variation.
Recommendations for Product Leaders
- Create one shared language: Define debt in terms business stakeholders understand.
- Make the cost visible: Track recurring effort, delays, incidents, and upgrade friction.
- Connect debt to outcomes: Connect technical constraints directly to business goals.
- Manage debt as a portfolio: Balance urgent risk reduction with continuous improvement.
- Build improvement into delivery: Set explicit capacity guardrails for engineering teams.
- Treat migration as part of the product: Plan customer onboarding, data, and readiness early.
- Measure changeability metrics: Track lead times, release frequency, and recovery speed.
💡 Are delivery bottlenecks slowing your roadmap?
If your engineering teams spend more capacity sustaining fragile systems than shipping new customer value, let’s talk. I help product leaders diagnose technical debt, reset delivery cadence, and unlock product momentum.
📧 Get in touch at aleksander@productuntangled.com