Why replacing technology isn’t enough to prevent recurring transformations.

“Requirements? It should work like the old system.”

An organization is preparing to replace a legacy application. The existing system has become expensive to maintain, difficult to change, and increasingly dependent on a few people who understand how it works. A major transformation promises to resolve these problems through modern technology, a cleaner architecture, and improved development practices.

The development team asks what the replacement system should do.

“Requirements? It should work like the old system.”

It sounds reasonable. The application has supported the business for years. But there is a problem. The organization knows what its system does, but no longer necessarily understands why.

Business rules are embedded in code. Exceptions and workarounds have accumulated. Important decisions were made years ago, and their rationale has disappeared. The old system has become the specification for its replacement.

Apparently, the old system is no longer good enough to keep, but its implementation is still considered good enough to copy.

From technical debt to understanding debt

Technical debt accumulates when compromises between immediate needs and long-term maintainability are not adequately managed. Architecture deteriorates. Dependencies become increasingly complex. Changes become expensive and risky. Eventually, replacing the system may become more attractive than maintaining it.

Technical debt has become technical bankruptcy.

But technical debt is often accompanied by another problem: understanding debt.

Over time, the organization loses the knowledge needed to explain what its products must accomplish and why. This becomes painfully visible during replacement projects.

Business analysts reconstruct requirements from existing behavior. Developers investigate undocumented business rules. Testers try to determine whether unexpected behavior is a defect or an undocumented requirement. The organization is paying to rediscover its own business requirements.

And the existing system becomes a reference object: a particular implementation used to define what the replacement must accomplish. A reference object is not the same as a reference model: an explicit description of the required behavior and characteristics, independent of any particular implementation.

The old system contains legitimate business requirements, but also historical compromises, obsolete assumptions, and accidental complexity. Without understanding why its behavior exists, the organization risks reproducing problems that should have been left behind.

When AI reconstructs the past

AI introduces an interesting development. We can now use AI to analyze source code and reconstruct requirements. We can then use AI to generate acceptance tests from those reconstructed requirements.

The process becomes:

Existing implementation → AI-reconstructed requirements → AI-generated acceptance tests → replacement implementation

This can dramatically accelerate requirements discovery and test generation.

But it introduces a risk. The reconstructed requirements describe what the existing implementation appears to do. They don’t necessarily establish what the business actually needs. And acceptance tests generated from those requirements may verify that the replacement reproduces existing behavior—including behavior that should have changed. The entire chain can be internally consistent without being correct against the business’s actual expectations.

We risk using AI to reproduce yesterday’s assumptions, compromises, and mistakes more efficiently.

This doesn’t make AI-assisted reverse engineering a bad idea. It can be an extremely valuable way to recover lost understanding. But reconstructed requirements should be treated as candidates for validation, not automatically as authoritative business requirements.

AI can help explain what a system does. Establishing what it should do still requires understanding business intent.

The problem that survives the transformation

Suppose the replacement succeeds. The organization now has a modern application, a cleaner architecture, and improved maintainability. During the transformation, considerable effort went into reconstructing business requirements, understanding existing behavior, and deciding what should be preserved.

But what happens to that understanding when the project ends? If the organization’s requirements management capability remains unchanged, the same pattern can gradually return. New functionality is introduced without preserving the reasoning behind important decisions.

Requirements become scattered across tickets, conversations, tests, and code. Testing discovers missing or ambiguous requirements, but resolving individual defects doesn’t necessarily improve the organization’s ability to establish requirements in the first place. Eventually, the new application becomes another system whose behavior is better understood than the reasons behind it. Understanding debt accumulates again.

The transformation has replaced the product.

But it hasn’t necessarily changed the organizational capability that allowed the problem to develop.

Two questions every transformation should answer

Organizations preparing for transformation naturally concentrate on what needs to change. Which applications must be replaced? Which architecture should be introduced? Which technologies and working practices should be adopted?

These are necessary questions. But a sustainable transformation requires another:

Why did the existing situation deteriorate until such extensive change became necessary?

The first question identifies what must change to address the current situation. The second investigates the conditions that allowed it to develop.

Those conditions may involve requirements management, quality engineering, architectural governance, product stewardship, management decisions, or other factors.

The objective is not to assume that every problem originates in a capability deficiency. It is to understand the causes and determine what must change to reduce the risk of recurrence.

Breaking the cycle

Not every transformation can or should be avoided. Business models change. Technologies become obsolete. Regulations evolve. New opportunities emerge. Sometimes extensive transformation is the right strategic decision.

But there is a difference between transforming because the business wants to move forward and transforming because the organization has lost the ability to maintain and evolve what it already has.

The first is a strategic choice. The second may be the accumulated consequence of organizational weaknesses that were never addressed.

Replacing a deteriorated system resolves the immediate problem. It doesn’t necessarily prevent the next one.

Maybe you will need a next transformation, but it shouldn’t be necessary for the same reasons as the last one.

---

Part II — Developing the Capability to Prevent Recurrence

The previous sections explain why replacing technology doesn’t necessarily eliminate the conditions that caused its deterioration.

The next question is practical:

How can an organization change those conditions rather than repeatedly deal with their consequences?

Consider requirements management as an example. If inadequate requirements management contributed to the loss of product understanding, producing better requirements during the replacement project is necessary but insufficient.

The organization must develop the capability to establish, maintain, and evolve that understanding throughout the product lifecycle. That requires a deliberate approach to capability assessment and development.

1. Investigate why understanding was lost

Start by examining how the old system became the primary source of its own requirements. Were business requirements ever explicitly established? Were decisions and their rationale preserved? Did requirements change without corresponding updates to the organization’s understanding?

Examine how other disciplines compensated for missing requirements. Perhaps testers routinely discovered requirements during test execution. Developers made assumptions when expectations were unclear. Product owners resolved individual questions without preserving the resulting knowledge.

These observations are starting points, not conclusions. The investigation should establish which causes are supported by evidence, including factors beyond requirements management.

2. Identify the capability that needs development

Next, determine what the organization must reliably be capable of doing. For requirements management, the objective is not simply to produce better requirements documents. It is to establish, validate, maintain, and evolve an adequate understanding of what products must accomplish and why.

That includes understanding business needs, making quality expectations explicit, managing changes, and preserving important decisions and their rationale.

Testing contributes by providing evidence about whether implemented behavior meets those expectations. But testing should not routinely substitute for establishing the expectations themselves.

The distinction between capability and practice is essential. Introducing requirements templates, reviews, or new tools doesn’t necessarily establish effective requirements management. A capability is demonstrated by what the organization can reliably accomplish.

3. Assess the current capability

Before deciding how to improve requirements management, establish how effectively it currently operates.

An assessment should examine evidence of actual work and outcomes, guided by explicit expectations.

For example:

• Can stakeholders explain why important functionality exists without relying exclusively on the current implementation?
• Are requirements sufficiently clear to support development and testing?
• Can the organization distinguish required behavior from historical workarounds?
• Are important quality characteristics addressed?
• When requirements change, are the rationale and consequences understood?

The assessment should distinguish evidence from interpretation and make uncertainty visible. Its purpose is to establish a credible understanding of the current capability—not to justify interventions already selected by management.

4. Prioritize capability development

An assessment may reveal several weaknesses. Perhaps business needs are poorly understood. Perhaps quality requirements are neglected. Perhaps decisions are made effectively, but their rationale disappears over time.

Not every weakness requires immediate attention. Management must determine which deficiencies create the greatest business risks and which improvements offer the most value.

For an organization replacing a legacy system, one objective might be:

Ensure that business requirements and their rationale remain sufficiently understood, accessible, and current throughout the product lifecycle.

This describes what the organization must become capable of accomplishing. It doesn’t prescribe the solution. The selected improvements could form a capability development backlog, with explicit ownership and expected outcomes.

5. Develop the capability through everyday work

Capability development can proceed incrementally alongside normal product development. A capability owner maintains the development backlog and coordinates improvements across product ownership, business analysis, development, and testing.

Initial interventions might focus on making important business rules and decisions explicit. Subsequent improvements could establish ways to validate requirements, preserve their rationale, evaluate changes, and incorporate knowledge discovered during testing and operations. A reference model can provide a useful structure for maintaining product understanding independently of a particular implementation.

AI can support this work by extracting candidate requirements, identifying inconsistencies, and helping maintain relationships between requirements, implementation, and tests.

But neither AI-generated requirements nor a completed reference model demonstrates that the capability has improved. The organization must become able to validate and maintain that understanding as the product evolves.

Completing an improvement activity is not the same as improving a capability.

6. Verify improvement and sustain the capability

Capability development requires evidence that the organization has become more capable. Can teams now establish requirements without relying exclusively on existing system behavior? Are important decisions and their rationale preserved? Do testers spend less time resolving fundamental ambiguities that should have been addressed earlier? Can the organization change its products without repeatedly reconstructing their business requirements?

Reassessment helps determine whether the intended improvements have materialized. If they haven’t, the organization needs to reconsider its interventions or its understanding of the problem.

But capability management shouldn’t end when the transformation closes. Business needs change. Products evolve. People leave. Maintaining the capability requires continuing ownership, evaluation, and development. Otherwise, today’s improvements may gradually become tomorrow’s weaknesses.

From recurring transformation to continuous capability development

Requirements management is only one example. The same reasoning applies to architectural governance, quality engineering, technical debt management, and other capabilities that contribute to long-term product health.

The objective is not to eliminate technical debt or prevent every future transformation. It is to develop the organization’s ability to recognize and address weaknesses before they accumulate into another crisis.

A transformation should therefore deliver two results:

A technology landscape better suited to the business’s needs—and an organization better capable of maintaining and evolving it.

The first addresses the immediate problem. The second reduces the risk of recurrence.

The real measure of transformation success is not only what the organization has changed, but what it has become capable of sustaining.