Zero Legacy Is Not a Strategy

The falling cost of producing code has revived an old ambition: eliminate the legacy estate and keep everything permanently current.

The ambition is understandable. AI coding agents can inspect unfamiliar repositories, draft tests, perform repetitive migrations, update dependencies, and reproduce a proven change across many components. Work that once sat in a roadmap for years can now move in weeks or days.

But “zero legacy” is not a useful business objective. It confuses the age of code with the cost of owning it.

Old code that is stable, understood, secure, and cheap to operate may be an asset. New code that nobody can explain, that changes faster than it can be verified, or that depends on a fragile vendor may already be legacy.

The AI productivity tool pushed too far

In a recent podcast conversation (transcription here and original version [fr]), Clever Cloud CEO Quentin Adam described using AI as part of a broad effort to reduce , and ultimately eliminate, roughly fifteen years of accumulated legacy code, with the goal of running only code written in 2026 by the end of the year.

That last statement genuinely struck me. Why on earth would we want to do that? Does the fact that something is possible necessarily mean that it is desirable? What is so problematic about relying on code that has been proven, tested, and has stood the test of time?

Perhaps it was simply a figure of speech, a more “catchy” way of saying: “We want to have addressed all our major technical debt initiatives by the end of the year.”

Or is it the symptom of a deeper unease that is gradually taking hold of the tech industry and its decision-makers?

Legacy is a business condition

A system becomes legacy when its constraints materially obstruct what the organization needs to do. Age may contribute, but it is not the definition.

These conditions can support a business case. “The code is old” cannot.

A debt register should therefore link each technical condition to revenue, operating cost, risk, delivery time, or a committed business plan. Once that connection is explicit, modernization can compete for capital on the same basis as other investments.

What AI makes cheaper

Used within a controlled engineering system, AI can reduce effort in several parts of modernization:

• Mapping dependencies and locating repeated patterns across a large repository
• Producing a first draft of missing tests around observed behaviour
• Explaining unfamiliar modules for review by an experienced engineer
• Applying a known migration pattern to many similar components
• Updating framework or library usage where the target is well specified
• Comparing interfaces and identifying likely compatibility gaps
• Producing documentation and decision records from reviewed source material

The common feature is not code generation. It is a bounded task with a source of truth and a way to verify the result.

This matters because much modernization work is repetitive rather than conceptually novel. Once a team has established a safe pattern for one service, module, or interface, an agent may help apply it to the next twenty.

What AI does not make disappear

The most expensive risks in a re-architecture often sit outside the act of writing code.

Hidden behaviour. Mature systems contain business rules that were never written down. Some are features. Some are accommodations for important customers. Some look like mistakes until they are removed.

Data migration. A new schema is easy to draw. Moving live data while preserving meaning, history, access control, and reconciliation is harder.

Cutover and rollback. The organization still needs to decide how old and new components will coexist, how traffic will move, and what will happen when the new path fails.

Operational readiness. Monitoring, incident response, support procedures, capacity planning, and security boundaries must work before the old path is retired.

Organizational ownership. New service boundaries fail when they cut across the way teams actually work. Re-architecture changes responsibilities as well as software.

Opportunity cost. Engineers and business specialists assigned to a rewrite are not delivering something else. Faster code generation reduces this cost, but does not reduce it to zero.

AI can help inspect and execute. It cannot accept these risks on behalf of the company.

The dangerous rewrite equation

A full rewrite is often justified with a simple comparison:

Maintaining the old system appears expensive. Producing new code now appears cheap. Therefore replacement must be cheaper.

The missing terms are discovery, equivalence, transition, and adoption.

The old system’s specification is rarely available in one place. It is distributed across code, data, tests, support tickets, contracts, user habits, and the memories of employees. A rewrite must discover which behaviour matters before it can reproduce or deliberately remove it.

AI can generate a plausible implementation before that discovery is complete. This makes the early project look faster. It does not make the missing knowledge less important. It can instead create a larger volume of software whose correctness still has to be established.

This is why code output is a weak measure of modernization progress. More useful measures include:

• Production traffic safely handled by the new path
• Reduction in change lead time for the affected business capability
• Reduction in infrastructure cost per useful transaction
• Incidents, rollback rate, and recovery time
• Old components, data paths, and operating procedures actually retired
• Business capabilities delivered before the program reaches its final state

Choose among five actions

Not every troubled system needs to be rewritten. A review should consider at least five options.

The result may be a mixed estate. That is not failure. It is often the economically correct target.

Re-architect around a constraint, not a fashion

Before approving structural work, name the constraint it will remove and the threshold at which the investment pays.

This protects the organization from two equal mistakes: preserving a harmful system because replacement feels dangerous, and replacing a useful system because new technology feels inevitable.

Modernize in slices that can survive contact with production

For many revenue-critical systems, the safest route is progressive replacement behind stable boundaries. Martin Fowler’s updated description of the Strangler Fig Application emphasizes desired outcomes, decomposition into smaller parts, delivery of those parts, and the organizational change needed to sustain the new system.

A practical sequence is:

1. Measure the current system under real load and cost.
2. Identify one business capability with a clear boundary and a meaningful benefit.
3. Define the interface between old and new paths.
4. Establish behavioural, performance, security, and cost tests before migration.
5. Move a controlled share of traffic, users, or data.
6. Compare results and exercise rollback.
7. Retire the old path only when its operational obligations have moved too.
8. Use what was learned to choose the next slice.

AI can accelerate several steps, especially analysis, test creation, and repetition of an established pattern. The migration remains evidence-led.

Healthy systems contain history

A well-run company should expect its software estate to contain code of different ages. Stable components preserve proven behaviour. Actively changing components absorb new requirements. Transitional components allow value to move without a dangerous cutover.

The goal is not zero legacy. The goal is an estate in which age does not determine risk, important behaviour is understood, costly constraints are visible, and every major replacement has a business reason.

AI makes more modernization options economically possible. Good technology leadership still has to decide which ones are worth doing.