From necessary evil to strategic edge: How Generative AI rewires the ROI of enterprise transformation (Part I)

When necessity kills momentum

There are projects every enterprise knows it needs to do, but very few people are excited to sponsor.

Legacy modernization. System migration. Process standardization. Documentation cleanup. Application rationalization.

These programs are important. In many cases, they are unavoidable. But they are still hard to prioritize properly.

The reason is simple: the business case has usually been framed too narrowly.

Most of the time, these projects are explained in terms of:

• Lower risk
• Lower maintenance cost
• Less disruption
• Reduced technical debt
• End-of-support remediation

All of that is valid. But it is defensive. It does not create momentum.

And in practice, these programs rarely start from a position of strength. They usually start under pressure. In Ensono’s 2025 survey, 49% of respondents said modernization was being driven by rising risk due to vulnerabilities, loss of software support, or downtime; 37% said they were struggling to release new products and features at the speed the business needed; and 32% said maintenance costs were eating up the IT budget. At the same time, technical debt and redundant applications continue to drive avoidable spend across IT portfolios.

So the project gets approved. But usually too late, under pressure, and with the wrong value story.

The bigger problem: these programs are also hard to execute

This is the second part of the issue.

It is not only that foundational transformation programs are hard to sell. They are also hard to land.

The success rates are not encouraging. McKinsey found that only 16% of respondents said their digital transformations improved performance and sustained the gains over time, with another 7% saying performance improved but the gains did not last. BCG found that only 30% of digital transformations met or exceeded target value and created sustainable change. IDC found that only about half of cloud migration projects were rated “successful” or “very successful.” And in Wakefield Research data cited by vFunction, 79% of application modernization projects failed.

These are different studies with different definitions, so I would not treat them as a single benchmark. But the pattern is clear enough: transformation is still underperforming.

And when you look at the reasons, they are not surprising.

Application modernization programs fail because expectations are badly set, the organization is not structured to support the target state, teams do not have the right tools, skills are missing, and complexity is underestimated. The same Wakefield study found that 97% of respondents expected pushback on a proposed modernization project, and nearly 50% said securing budget and resources was the hardest step. Cloud programs fail for similar reasons: lack of cloud skills, lack of standards, integration issues, performance and reliability problems, weak leadership support, and poor control of cost.

So this is the real context.

These projects are triggered by pressure, justified defensively, and executed in conditions that make success harder than it should be.

Survey data shows modernization is most often triggered by risk, speed constraints, cost pressure, and tech debt.

This is where Generative AI matters

I think there is a tendency to frame Generative AI only around new products, new interfaces, or new customer experiences.

That is part of the story, but not the whole story.

Some of the most immediate enterprise value is elsewhere: in improving the economics and execution of the transformation work companies already need to do.

That matters because AI changes the equation in two ways.

1. It improves execution

A large share of the drag in transformation programs comes from manual effort, poor visibility, and weak knowledge transfer.

That shows up in very practical places:

• Understanding legacy code
• Discovering dependencies
• Documenting behavior
• Generating tests
• Planning transitions
• Extracting knowledge from fragmented sources
• Helping teams work through systems they did not originally build

This is where Generative AI is useful in a very concrete way.

It helps reduce ambiguity. It helps surface structure in places where people are used to working around uncertainty. And it makes some of the hidden effort in these programs easier to manage.

That does not remove the need for strong architecture, governance, or delivery discipline. But it does reduce the execution burden.

2. It increases the value of the destination

This is the more important shift.

If AI only made migration or modernization cheaper, it would still be useful. But that would be a limited story.

The bigger point is that the destination becomes more valuable once the transformation is done well.

A better target environment means:

• Cleaner interfaces
• More modularity
• Better reuse
• Better automation potential
• Stronger AI readiness
• More flexibility for future change

So the transformation is no longer only about reducing cost or retiring risk. It is also about building a more usable, adaptable, and scalable operating environment.

That is where the ROI changes.

One practical bottleneck: AI needs a usable project context

This is the part I think gets missed in a lot of enterprise discussions.

People say AI can help migration. That is true.

But in most migration programs, the context AI needs is not organized in a way that makes it reliably useful.

The source code exists. The business knowledge exists. The project information exists. The migration decisions exist.

But they are usually spread across too many places, at different levels of quality, with different owners, and no consistent structure.

That means teams are not only struggling with legacy systems. They are also struggling with fragmented project context.

And that matters because AI is only as useful as the context it can work with.

That is one of the reasons we have been building an internal platform to support complex migration work.

What we are building

We are developing an internal platform for migration teams that acts as a shared artifact layer between humans, coding agents, and the target system design process.

The idea is not just to store documents. It is to create a governed workspace where migration knowledge can be generated, refined, reused, and acted on.

What matters most is not the workflow mechanics. It is the potential this creates.

Coding agents can analyze legacy source code and generate structured artifacts into the platform through MCP. That means the raw analysis does not stay trapped inside a one-off prompt or in a notebook on one person’s machine. It becomes part of the project knowledge base.

Those artifacts can document things like:

• Business rules
• Architecture
• Functional requirements
• Non-functional requirements
• Migration risks
• Technical stack
• System boundaries
• Dependencies
• Assumptions that need validation

That is a very different operating model from the way many migration projects still run today.

Instead of treating source-code analysis as an isolated activity, it becomes part of a shared and evolving body of project knowledge.

The key shift is a shared artifact layer where humans and agents build, validate, and reuse project knowledge across legacy and next-gen work.

The important part is what happens next

What makes this interesting is not only that coding agents can generate artifacts.

It is that those artifacts can then become usable context for the next phase of the transformation.

Once you have an artifact base that captures the current system in a more explicit way, coding agents can read from it when working on the next-generation system.

That changes the flow.

Instead of asking an agent to generate a target-state component from a thin prompt, you can give it a much stronger context:

• The extracted business rules
• The interpreted architecture
• The functional requirements
• The non-functional requirements
• The migration risks
• The current tech stack
• The known gaps and constraints

That makes the work more grounded.

The target-state design is no longer based only on a human summary of the old system. It can be informed by a growing body of structured artifacts generated and refined through the migration program itself.

This is where the value starts to compound.

The same project knowledge that helps explain the old system can help shape the new one.

Conclusion: When transformation starts to compound

What changes in this model is how value is built over time.

Once transformation work produces structured, reusable artifacts, it stops being a one-direction effort. The same knowledge that explains the existing system starts shaping the future one.

That is the inflection point: transformation begins to compound.

Instead of isolated activities, teams build a growing knowledge base that improves both understanding and delivery.

What comes next

In Part 2, we move from this foundation to scale:

• how multi-agent orchestration builds on structured artifacts
• how human–agent collaboration evolves into a new operating model
• and how this approach can turn transformation into a repeatable capability