In Part 1, we explored how Generative AI improves transformation work at its core:
This already improves execution.
But the bigger shift happens when this foundation is used to scale.
Because once transformation knowledge becomes structured and reusable, it can support not just individual tasks, but coordinated systems of work.
The next step is not just single-agent assistance.
The bigger opportunity is multi-agent orchestration running on top of the artifact base.
Different agents can take on different types of work:
That starts to create a more scalable transformation model.
Not because agents replace engineering teams. But because they can take on more of the repetitive analysis, synthesis, and structuring work that usually slows teams down.
And importantly, humans still stay in the loop.
The artifact base is not there to bypass collaboration. It is there to improve it.
I do not think the right model here is “let the agents do the migration.”
The more credible model is:
That is the practical shift.
Humans are not just prompting from the outside. They are working with agentic assistants inside the same knowledge space, further improving and collaborating on the artifacts as the migration progresses.
That matters because transformation programs are never just technical translation exercises. They involve interpretation, judgment, trade-offs, validation, and alignment.
So the operating model I find most useful is not “AI replacing delivery.” It is:
Humans and agents collaborating on structured transformation artifacts.
That is a much stronger foundation for complex migration work.
System migration is a good example because the problem is easy to see.
Traditional migration programs are usually slowed down by:
That is why they feel slow, risky, and expensive.
AI can help with parts of that. But it helps much more when the project has a structured artifact base that agents can read from and contribute to.
That gives the migration team a way to:
That is what we are trying to solve.
Not by pretending a platform replaces migration expertise. It does not.
But by creating a better knowledge layer for migration teams and the coding agents supporting them.
For years, most foundational transformation programs have been judged on a simple logic:
That is the destination.
And then on the execution side:
That is why these projects often look unattractive even when they are necessary.
The value side is too narrow. The delivery side is too heavy.
That is the old equation.
In practical terms, the project feels like this: we are being forced to do something difficult, expensive, and disruptive, mainly so that things do not get worse.
That is not a strong value proposition.
The better way to think about transformation ROI is this:
On the destination side, the value is not just:
It is also:
On the execution side, complexity still exists, but its effective weight can be reduced when you improve:
That is the shift I find most useful.
Not “AI solves transformation.”
It does not.
But AI can improve the conditions under which transformation is executed, and it can improve the business value of what the organization gets at the end.
And if you want that to work in real migration environments, you need more than a model. You need a structured way for humans and agents to build, refine, and reuse project knowledge together.
If I had to pick one example where this becomes very tangible, it would be system migration.
Traditional migration programs usually start with familiar triggers:
And the work itself is usually slowed down by familiar issues:
That is why migration often feels like a necessary evil.
But AI-assisted migration changes the shape of the work.
You can accelerate discovery. You can generate documentation. You can make dependencies more explicit. You can reduce some of the manual burden in planning and testing. You can turn source-code analysis into reusable artifacts. And you can let coding agents use those artifacts again when building the target state.
Then the value of the target state becomes broader:
So the migration is no longer just a remediation exercise. It becomes part of capability building.
That is a much stronger position for the business case.
Migration is just the clearest example.
The same pattern shows up in other parts of the enterprise:
These are not always attractive programs. But they are foundational. And in many organizations, they are exactly the kinds of programs that slow down future change if they are delayed too long.
Generative AI helps here for the same reason: it improves visibility, reduces manual effort, supports execution, and increases the value of the resulting foundation.
But again, it works best when the work is structured well enough to support it.
These programs rarely show up as a single initiative. They show up as a portfolio of “forced” work.
If the old model was too narrow, then leadership questions also need to change.
Instead of asking:
A better set of questions is:
That last point matters.
Because if you still evaluate foundational transformation only through risk and cost, you are probably using an old model for a different environment.
I do not think Generative AI makes foundational transformation glamorous. That is not the point.
What it does is more useful.
It helps turn these programs into something with a better execution profile and a better value profile.
And if organizations want to use AI seriously in migration work, they need to go beyond one-off prompts and isolated copilots. They need a better way to:
That is the thinking behind the platform we are building internally.
Not as a replacement for migration expertise. But as a better knowledge and execution layer for complex migration work.
Because many of the projects that shape the future of the enterprise are not the exciting ones at the edge. They are the ones in the foundation that everyone knows are necessary, but few know how to position, or execute, well.
If Generative AI helps reduce complexity, reduce uncertainty, and broaden the value of the destination, then these programs should stop being managed as necessary evils.
They should be treated for what they are:
strategic investments in enterprise capability.