Brownfield, not Greenfield: Why AI-Assisted Legacy Software Modernization Fails Without the Old System's Rules

For twelve months, a large organization tried to modernize its application portfolio by letting AI rewrite the code. According to BCG, the AI-generated changes were accurate only about 30% of the time, and they often created more work than they saved. Accuracy rose to 85% when the team stopped relying on the model alone, built a fact-based map of how each application actually worked, and fed that map to the AI.

The model didn't change, it just got an upgrade in what it knew.

That is the central problem of legacy software modernization with AI. In our last article, we looked at the unwritten engineering rules teams run on every day. Legacy systems are where those rules accumulate the longest: years of business logic, with exceptions and dependencies that no specification fully records. Generate modern code without them, and you don't remove technical debt. You simply move it to a newer stack.

How do you fix this?

The short answer is sequence. Extract and validate the old system's rules first. Rewrite with AI second. Modernization works when it is brownfield, not greenfield.

Key Takeaways

• Legacy application modernization fails less on code generation than on comprehension of what the old system actually does.
• Legacy systems enforce business rules, exceptions, and dependencies that no specification fully records.
• AI that rewrites from code or specs alone rebuilds the documented system, not the running one, and moves technical debt to a newer stack.
• Extracting and validating the existing rules comes first; AI-assisted rewriting comes second.
• Brownfield modernization means new code is generated inside the existing architecture and standards, not in a vacuum.

Why Greenfield Thinking Breaks Legacy Software Modernization

Greenfield thinking assumes the starting point is complete. Take the specification or the code, treat it as the full description of the system, and generate a clean, modern version. On a new product, that assumption holds. But on a system that has been patched for 15 to 30 years, it doesn't.

The choice of strategy, whether rehost, refactor, rearchitect, or replace, is covered in our legacy system modernization guide. Every one of those strategies has the same precondition: you have to know what the current system does before you can preserve it. Greenfield thinking skips that step, because it assumes the answer is already written down.

What the Old System Knows That the Specification Doesn't

Legacy systems are full of rules that exist only in their behavior. Three examples are typical of what turns up in a long-lived estate:

• A rounding rule: one currency rounds half-down because a regulator required it in 2009. The spec says "round to two decimals."
• An exemption flag: accounts migrated during an old acquisition carry a field that exempts them from a fee that everyone else pays. Nobody documented why.
• An ordering dependency: a nightly batch job must finish before another one starts, because a downstream regulatory report reads its output. The dependency lives in the scheduler, not the code.

None of these appears in the original requirements, yet all of them matter. BCG describes this as a type of drift: through patches, workarounds, and undocumented changes, actual behavior diverges from the original specifications. The specification describes the system someone intended to build, while the running system is the one the business depends on.

Why a Model Reading Code Alone Rewrites the Wrong System

The obvious fix is to skip the documents and point AI at the code. The code, at least, is current. But code alone hides configuration-driven behavior, undocumented integrations, and environment-specific logic. For example, a rule might be enforced by a database trigger, a parameter table, or a job that runs only at month-end.

Generic AI models will still produce an explanation. BCG warns that, unless grounded in reliable analysis, AI can deliver convincing narratives that are not entirely accurate, and that those inaccuracies compound as the model works through a large codebase. Every misread rule becomes an input to the next inference.

This is the difference between a bigger prompt and real context engineering. Giving a model more code to read doesn't tell it which behavior is intended, which is accidental, and which the business has quietly come to rely on.

How AI-Assisted Software Development Moves Technical Debt to a Newer Stack

Technical debt is already expensive. A McKinsey survey of CIOs found it can represent 20% to 40% of the value of an entire technology estate. Modernization is supposed to pay that debt down.

A rewrite generated without the old system's rules does the opposite. It translates today's debt, the undocumented logic and accidental behavior, into a new language, then adds a second layer on top: the rules it dropped and the inconsistencies it introduced.

Lost Exceptions Become Production Incidents

A dropped rule doesn't fail in testing if nobody knew to test for it. It fails after cutover, against live data, under time pressure. The exempted accounts get charged and the regulatory report runs on incomplete data. The fix is made in production, by engineers who now have to reverse-engineer the old system anyway, only later and under worse conditions.

BCG describes a major transportation operator that used AI agents to rewrite legacy code and got unreliable results: too many silent breaks and undocumented dependencies. The fix wasn't a better model. The operator spent one week building a trusted map of how the system worked, including every dependency and data flow. After that, it could produce credible estimates and meet its timelines. In regulated sectors such as banking, the cost of a silent break also includes the audit finding that follows.

Duplication and Drift Arrive With the New Code

The second layer of debt is structural. GitClear's analysis of 211 million changed lines of code, reported by LeadDev, found an eightfold rise in duplicated code blocks during 2024. In the same year, copy-pasted lines exceeded moved lines, the signature of refactoring and reuse, for the first time.

In a modernization process, that pattern is hard to undo. An AI that doesn't know the company's approved libraries, shared services, and conventions will solve the same problem differently in each module. The new stack starts life with engineering drift already built in, before a single user has logged in.

Rules First: What Extraction and Validation Look Like in Practice

The fix is a change in sequence, not a change in tooling. Organizations using the right AI with the right context for the right task can cut modernization costs and implement changes faster.

Getting the context right starts with the following five steps.

1. Map the System From Evidence

Start with what the system demonstrably does, not what anyone says it does. Static analysis lays down the structure: call graphs, dependencies, data access patterns. Runtime telemetry, such as logs and traces, shows which paths actually execute in production. Deterministic analysis comes first; AI narration comes second, grounded in that map.

This is where most of the schedule risk sits. Thoughtworks describes a European automotive manufacturer whose program was nine months behind, stuck reverse-engineering a 15-million-line codebase. Using generative AI on that analysis cut reverse-engineering time by two-thirds, which is the kind of work enterprise architecture teams already own.

2. Extract Candidate Rules With AI, From Several Lenses

No single source holds every rule, so look through several. Code for logic, UI flows for what users are allowed to do, and data lineage and change data for which actions change which records.

Thoughtworks applied this multi-lens approach to a legacy system with no available source code, reconstructing a functional specification from UI elements, binaries, and data lineage. AI was used to summarize, connect, and draft. The output at this stage is a list of candidate rules, not requirements.

3. Validate Every Rule Before It Becomes a Requirement

A candidate rule is a hypothesis. Domain experts confirm it, correct it or reject it. In the Thoughtworks pilot, as InfoQ reports, AI drafted candidate rules, and humans validated the results from multiple perspectives.

Validated behavior that must not change is then pinned down as tests and acceptance criteria. These become the definition of done for the new system. Rules nobody can confirm stay flagged as open questions, instead of getting quietly accepted or dropped.

4. Encode the Validated Rules Once, Where Generation Can Use Them

Validated rules are only useful if every future change sees them. They belong in one governed layer, alongside the company's architecture, approved libraries, design system and QA definitions. Every request passes through that layer, and the relevant rules are assembled before the model writes anything.

This is the role of an enterprise context layer. The rules are encoded once and enforced on every change, rather than re-explained in every prompt. When a new rule conflicts with an existing one, it is flagged for an owner to resolve.

5. Generate Against the Rules, Then Verify Against the Old System

Only now does AI-assisted rewriting start. Context-aware code generation produces code inside the existing architecture: the same APIs, the same conventions, the same validated rules. Replace the system in thin slices, routing traffic to each new component before retiring the old one, as in Martin Fowler's strangler fig pattern.

Then prove equivalence. Run the old and new versions against identical inputs and compare outputs. Every divergence is either a bug in the new code or a rule nobody captured.

What to Ask Before Choosing Legacy Modernization Software

Most legacy modernization software is sold on generation speed. In a brownfield program, the questions that matter are about what the tool knows, and how you prove it was right.

Does the tool extract rules, or only translate code? Translation turns one language into another, bugs and accidental behavior included. Ask to see the rules a tool produces from your system, in a form a domain expert can review.

Who validates extracted rules, and how? An AI-drafted rule should never become a requirement without a named person confirming it. Ask how unconfirmed rules are flagged and how conflicts between rules are resolved.

Does generated code follow our existing architecture, libraries and standards? Code that is correct but built differently from everything around it is a second round of work. Ask what the tool retrieves before it generates: design systems, approved libraries, architecture patterns, business rules.

Can every change be traced and audited inside our perimeter? Regulated sectors need to show who changed what, and why. Ask whether the platform runs in your own infrastructure and keeps an audit trail for AI-generated code.

What AI Still Can't Do in Modernization

AI shortens the slowest parts of modernization: reading old code, drafting rules, generating new components. However, it doesn't remove the people who decide what the system should do.

Domain experts still have to confirm which behavior is intentional. Old and new systems still have to run in parallel before cutover. Backend changes still need human review before they reach production, and reviewers need enough context to judge what they are approving, a problem we covered in the AI code review bottleneck.

In aviation, banking, or healthcare, certification and audit still set the pace. AI makes each of those steps faster and better evidenced, but not optional.

Conclusion

In legacy software modernization, the old system is the specification. Its rules are scattered across code, data, schedules, and the heads of a few senior engineers, and most of them were never written down. Generating new code before those rules are recovered doesn't modernize the system. It just rebuilds the documented version and leaves the business to rediscover the rest in production.

Teams that succeed reverse the order. They map from evidence, extract candidate rules, validate them with the people accountable for them, and encode them once. Then they generate inside the architecture they already run, and prove the new system behaves like the old one.

That is the problem DesignVerse is built around. It generates software inside your existing architecture and standards, from a governed context layer your architects control, running in your own infrastructure. It's how we approach mission-critical work in aviation and air traffic management, where software that doesn't conform is a regulatory issue, not only a functional one.

Find out how much engineering drift is costing you, or request a demo to see brownfield modernization on your own stack.

FAQs

What is brownfield modernization?

Brownfield modernization updates software inside the existing architecture, data and standards rather than rebuilding it from a blank slate. It preserves the behavior the business depends on while the underlying stack changes.

Why does AI-assisted legacy modernization fail?

Generic models don't know the undocumented rules, exceptions and dependencies the old system enforces. They rebuild the documented system, not the running one, and the gaps surface after cutover as incidents and rework.

How do you extract business rules from a legacy system?

Combine deterministic analysis of code and data with AI-drafted candidate rules from several sources: code, UI flows, data lineage and logs. Then have domain experts validate each rule and pin the confirmed behavior down as tests.

Can AI legacy modernisation work without source code?

Partly. Thoughtworks has reconstructed functional specifications of a black-box system from its UI, binaries and data lineage. Human validation remains essential, because inferred rules are hypotheses until someone confirms them.

How is legacy software modernization different from a rewrite?

A rewrite replaces code. Legacy software modernization keeps the behavior the business relies on, proves the new system matches it, and usually replaces the old system incrementally rather than in one cutover.