Fixing Your Legacy Codebase Isn’t Enough. Fix Your Change Path Too

The Pattern

This pattern shows up long before anyone calls the code legacy.

Teams in this position ship every sprint. Their delivery is unstable, their unplanned work is high, and their throughput looks fine right up until someone asks what actually shipped. The bottleneck isn't inside any one team's work. It's in the system that work moves through.

Google's DORA research program surveyed technology professionals in 2025 and sorted them into seven team profiles. One profile, representing 11% of the sample, was named the Legacy Bottleneck.

11% of DORA’s sample fell into the Legacy Bottleneck profile.

Google DORA, 2025 State of AI-Assisted Software Development

If that fits, you're not an outlier and you're not badly run. You're in a category common enough that researchers gave it a label, and the teams in it aren't working less than anyone else. They're working inside more friction.

Here's the harder part.

You've probably already read four articles about this. You know the vocabulary. You've run some version of the checklist and confirmed what you already suspected: the codebase is old, the tests were never finished, and the documentation was never kept up.

All of that is real, and all of it is worth fixing. The diagnosis wasn't wrong. It stopped at one level too early.

There are two things to measure here, and they're connected, not separate. A legacy system has two problems: the condition of the system, and the path a change takes to reach production. The condition of the system determines how difficult and risky a change is.

The change path determines how long that change waits, how large it has to become before it ships, and how hard it is to reverse. Modernization holds only when a program improves both. Most legacy assessments measure only the first. Improve the condition of the system while leaving the change path unchanged, and the same constraints can return.

The Symptoms

Most articles on this topic list the same four signs. The signs are real, but they do not all live in the code. One concerns testing, another concerns people, and another concerns the boundaries between modules. Together with tight coupling, they describe the condition of the system.

Here they are, compressed, with what each one actually costs.

We won't walk through all four. They're well documented, and you've read them before. The first one is worth expanding, because it's where we learned this.

Somewhere in our early years, a module was built to do one job well. By year 15, everything touched it. Not by design. By accumulation, one reasonable decision at a time, each made by someone who had no way of seeing the twentieth one coming.

A small change to that module needed three engineers and a two-week review cycle.

The review cycle wasn't the signal. The signal was a shift in the questions our engineers asked. They stopped asking how to build something. They started asking what it would break.

That caution was rational. Every one of them was right to be careful. And it had already been priced into every estimate we received, which meant we'd been paying for it for years without ever seeing a line item.

If your estimates have quietly inflated over the last two years and nobody can point to why, that's the same mechanism.

These signs rarely appear as named issues on a sprint board. Instead, they show up indirectly through inflated estimates, delayed releases, slower onboarding, and deferred refactors. You see them most clearly when the team tries to change the system.

Every row in that table describes the condition of the system. That is the first of the two things worth measuring, and it is the one you have probably already done.

The Proof

We initially assessed only the condition of our own system, and that gave us only part of the picture.

We built a sales force automation platform 16 years ago. It served customers reliably for years, and clients trusted it. That reliability was an achievement we wanted to preserve as the product continued to evolve.

As the product grew, the architecture underneath it hadn't evolved at the same pace. The system was still delivering value, but it couldn't keep pace with what we wanted to build on top of it. That wasn't an easy case to make internally. Nothing was broken.

Before making changes, we spent weeks understanding what we had. We mapped what the system actually was, and how a change actually moved through it, from development to production. Historical documentation was a starting point, but we needed to understand how the system worked today.

That diagnosis gave us a clearer picture.

We found the four signs described above. We also found constraints in the path each change took to reach production. Strengthening the product meant addressing both the condition of the system and the way we changed it.

The Dianostic

Every codebase that remains useful long enough gets old. Age alone is not what makes it legacy.

The question is whether a change can still travel through your organization safely. That's a different thing, and it's measured differently.

Here are 10 questions. The first five are the ones most articles give you. The second five reveal whether the change path could recreate the same constraints after modernization. Column A tells you why a change is technically difficult. Column B tells you why that change takes so long to reach production. A modernization program has to address both, not choose between them.

• Can a new engineer modify any module without asking for help?
• If a critical path breaks, does a test catch it before a customer does?
• Can you describe your architecture without asking a senior engineer first?
• Can you change one module without rebuilding, retesting, or redeploying unrelated modules?
• Can you add an integration without touching existing modules?

• How many approvals does a low-risk, independently deployable change cross?
• How many approval steps depend on one specific person being available?
• How long does a change wait between stages, versus how long does the work itself take?
• What is the smallest low-risk change that can move through the standard approval process without being bundled into a larger release?
• When a release fails, how long does the team wait for rollback approval before recovery can begin?

A pattern of “no” answers in Column A confirms the system-level constraints you already suspected.

Column B is different because it can't be answered from memory. It has to be counted. Take one change that shipped last month and trace it. Every approval it crossed. Every queue it sat in. Then split the elapsed time into two numbers: the hours someone was working on it and the hours it spent waiting for someone to be available.

Most delivery tooling reports the first but does not consistently capture the second.

We had the same blind spot. Go back to that module from year 15. Three engineers, two weeks, and we never once asked how much of that was writing code.

Teams do the work in Column A. They fix the coupling, add the tests, write the documentation, and draw the boundaries. Eventually the estimates start climbing again.

That isn't a failure of execution. It's what happens when the code changes and the path doesn't.

The Evidence

We are not the only ones who ended up looking past the code.

In 2025, Forrester asked 593 IT professionals what technical debt actually means inside their organizations.

Forrester's 2025 Modern Technology Operations Survey

Worth translating those categories, because they sound abstract until you name them. Knowledge debt is the architecture that lives in people's heads. Process debt is the six approvals a change collects on its way to production, added one at a time, never reviewed as a set.

That ordering matters. Fewer respondents named code quality than knowledge and process debt. This suggests that practitioners define technical debt more broadly than code quality alone. A program aimed only at the code addresses the narrowest reading of the problem. It will succeed on its own terms and change less than expected.

It matched what we found on our own platform, though we didn't have a name for it at the time.

The four signs above describe the condition of the system. That is why knowing them was never going to be enough on its own.

That is why Column B asks about approvals, queues, and batch size rather than about coverage. Leaving those change-path constraints unchanged also carries a cost.

The Stake

None of this appears as a line item, which is how it survives budget reviews.

It arrives instead as slightly longer estimates, slightly more careful releases, and a roadmap that gets quietly shorter each quarter.

Technical debt estimated at 21% to 40% of IT spending
Deloitte, 2026 Global Technology Leadership Study, 662 senior technology leaders

$754M a year to run 11 federal systems aged 23 to 60 years
US Government Accountability Office, July 2025

Deloitte surveyed 662 senior technology leaders for its 2026 study, most of them C-suite, at organizations above a billion dollars in revenue. Deloitte estimates that technical debt accounts for 21% to 40% of IT spending, roughly one-fifth to two-fifths of the technology budget.

The GAO found something sharper. Across 11 federal systems aged between 23 and 60 years, seven carried known security vulnerabilities that cannot be remediated without modernizing the system.

That last clause is the one to take to your board. Deferring modernization doesn't hold your risk flat. It converts a cost problem into a security problem that can no longer be patched.

Standing still isn't a cheap option. It's the option whose invoice arrives later.

The Loop

Here's the question the category rarely asks.

Why does a modernized system become legacy again?

It isn't a comfortable question for anyone selling modernization, which may be why it rarely gets asked.

Teams reach for three answers when they hit the wall: patch, refactor, or rebuild. Each is defensible, and each has been chosen by people who understood their system better than any generic checklist could

Patching is fast and cheap, and each patch can become another constraint the next engineer works around. The structure doesn't improve. It accumulates.

Refactoring is the rational choice on a whiteboard. During a prolonged refactor, the codebase is half old and half new. The old modules don't integrate with the new ones, the new ones aren't finished, and the product is stable in neither direction.

Rebuilding in our experience often requires 18 to 24 months. A full team works on the new system while the old one keeps clients running. Two systems in production, and a migration at the end that still has to be survived.

To be fair to all three, each is the right call somewhere. A patch is correct when the system is being retired next year. A rebuild is correct when the platform genuinely cannot carry what the business now needs.

Three different answers. One identical right-hand column.

The condition of the system and the change path reinforce each other. Weak tests and unclear boundaries make a team more cautious about changing the system. That caution produces larger releases, more approvals, and longer queues, because bundling changes together and reviewing them more heavily feels safer than shipping small and often.

Larger, slower changes can then create more coupling, more context loss, and more uncertainty, which makes the next change riskier still. Neither side is the root cause.

Neither side is the single root cause; each reinforces the other. The four signs can therefore appear as both causes and consequences. Modernization that rewrites the code but leaves the change path unchanged can restart the cycle.

If the change path remains outside the project, the new system can inherit it on day one. Same approvals. Same batch sizes. Same caution, because the people are the same people and the review process was never the thing being replaced.

Given time, the new system shows the same four signs on a stack that was new when the project started.

That isn't bad luck, and it isn't bad engineering. The change path that produced the first legacy system was never part of the project, so it can recreate the same conditions in the new one.

The Fix

When we worked out what to do with our own platform, we stopped asking which of the three paths to take. We asked a different question. What would any fix have to satisfy in order to hold?

We landed on four conditions.

• Understand what you actually have. Not what the documentation says. This is why weeks went into diagnosis before anything was changed.
• Validate at every step. If quality is checked only during integration, problems are discovered when they are most expensive to fix.
• Change incrementally. The product must keep serving clients while it changes underneath them, which rules out anything with a big-bang cutover.
• Transfer knowledge as you go. Otherwise, the architecture ends up redistributed into three more people's heads instead of written down.

Any one of them is achievable. All four at once is the hard part, because each one makes the others more difficult.

Incremental change complicates validation, because you're validating a moving target. Knowledge transfer slows delivery in the short term, which makes it the first thing cut when a deadline appears.

Now read the four again and notice something.

Not one of them is about the code.

That's the Forrester finding arriving from a different direction. Respondents named knowledge and process debt more often than code quality.

Every condition is a rule about how change gets made, approved, and recorded. The code still has to be fixed. These four conditions are what make the fix hold.

We chose to refactor. No open-ended module-by-module rewrite. No mid-flight limbo. Story by story, with the product serving clients throughout and getting cleaner each cycle rather than more fragile.

The modernization choice was refactoring. What changed was the method.

Agent Arjun is our method for modernizing both sides at once: the condition of the system, and the path each change takes to production.

We turned those four conditions into a governed pipeline. Human approval sits where it reduces risk rather than wherever history adds a gate. Every handoff produces a documented output. The approved specification travels with the change, so each stage validates against something written down rather than someone's recollection.

That means more checkpoints in some places, not fewer. Some checks are automated or role-based, while human approval is reserved for defined risk points.

The Exception

When we worked out what to do with our own platform, we stopped asking which of the three paths to take. We asked a different question. What would any fix have to satisfy in order to hold?

We landed on four conditions.

• Understand what you actually have. Not what the documentation says. This is why weeks went into diagnosis before anything was changed.
• Validate at every step. If quality is checked only during integration, problems are discovered when they are most expensive to fix.
• Change incrementally. The product must keep serving clients while it changes underneath them, which rules out anything with a big-bang cutover.
• Transfer knowledge as you go. Otherwise, the architecture ends up redistributed into three more people's heads instead of written down.

Any one of them is achievable. All four at once is the hard part, because each one makes the others more difficult.

Incremental change complicates validation, because you're validating a moving target. Knowledge transfer slows delivery in the short term, which makes it the first thing cut when a deadline appears.

Now read the four again and notice something.

Not one of them is about the code.

That's the Forrester finding arriving from a different direction. Respondents named knowledge and process debt more often than code quality.

Every condition is a rule about how change gets made, approved, and recorded. The code still has to be fixed. These four conditions are what make the fix hold.

We chose to refactor. No open-ended module-by-module rewrite. No mid-flight limbo. Story by story, with the product serving clients throughout and getting cleaner each cycle rather than more fragile.

The modernization choice was refactoring. What changed was the method.

Agent Arjun is our method for modernizing both sides at once: the condition of the system, and the path each change takes to production.

We turned those four conditions into a governed pipeline. Human approval sits where it reduces risk rather than wherever history adds a gate. Every handoff produces a documented output. The approved specification travels with the change, so each stage validates against something written down rather than someone's recollection.

That means more checkpoints in some places, not fewer. Some checks are automated or role-based, while human approval is reserved for defined risk points.

If Column B came back badly, three things are worth reading next.

Patch, refactor, or rebuild takes each path apart properly, including the one we chose for our own platform and what it cost us.

AI-assisted or AI-native covers the question engineering leaders keep being asked: whether AI coding tools can get you through this on their own. The research is more interesting than marketing.

Inside Agent Arjun explains the pipeline: the six agents, what each one receives and produces, and where the human checkpoints actually sit. We named it after the archer of the Mahabharata. Precision, discipline, one target at a time.