Why we're building a migration platform for humans and coding agents

Here's something that took me a while to fully appreciate: most migration programs break long before they hit the architecture. The failure point is earlier, and the reasons are more mundane.

The team doesn't have a solid enough grip on the current system. Project context is scattered across too many places. Documentation is thin. Decisions are made in calls and forgotten in threads. Critical knowledge lives in the heads of two or three people who are already stretched thin.

None of that is new. What's changed is that Generative AI makes this problem impossible to ignore.

AI can help with migration work — I think that's well established at this point. But what gets less attention, and what I think matters more, is that AI only becomes genuinely useful in serious migration programs when the project has a structured knowledge layer that both humans and agents can work against.

That's why we're building an internal migration platform.

Not to pile another tool onto an already crowded delivery environment. Not to “put AI on top” of migration work as a cosmetic upgrade. We’re building it because migration teams genuinely need a better way to:

organize project knowledge
make that knowledge reusable across the life of the program
expose it safely to AI systems
let humans and agents work on the same body of artifacts over time

For complex migration work, that structured knowledge layer has become part of the operating model.

Why migration needs a better operating layer

Migration programs almost always kick off under pressure. Support is ending. Risk is climbing. Maintenance costs are eating the IT budget. The current platform is too brittle to keep up with delivery. Everybody knows something has to change.

That pressure is real. Ensono's 2025 survey found that 49% of respondents said modernization was being driven by increasing risk from vulnerabilities, support loss, or downtime; 37% said they were struggling to release products and features fast enough; and 32% said maintenance costs were eating up the IT budget.

But urgency doesn't automatically produce execution quality. And that's exactly where most programs hit trouble.

The system might be old, but the deeper problem is usually that the team doesn't have a clear, governed, shared understanding of:

what the system actually does
which business rules matter
where the dependencies are
what the non-functional constraints are
what the risks are
what assumptions are still unvalidated

Some of that knowledge exists somewhere — buried in a ticket, implied in a slide deck, locked in someone's head. But rarely in a form that's structured, current, and actually reusable.

That matters because migration is a knowledge problem as much as a technical rewrite or platform change.

The problem AI exposes

There's understandable excitement right now about applying AI to migration work. Coding agents can already do genuinely useful things:

source-code analysis
dependency detection
documentation generation
test support
design assistance
code generation for target-state systems

But there's a practical constraint that doesn't get talked about enough: AI needs context. And in most migration programs, the context is a mess.

Project briefs sit in one place, meeting notes somewhere else, architecture docs are out of date, requirements are partly formal and partly implied, business logic is buried in source code, and migration decisions are spread across calls, tickets, decks, and chat threads.

You can still use AI in that environment. But the output will be inconsistent, because the input environment is inconsistent.

That's the gap we're trying to close.

What the platform is meant to do

At its core, the platform is a shared artifact layer for migration programs. It gives teams a structured workspace where migration knowledge can be created, refined, governed, and reused across the full life of a project.

Beyond document storage, the platform creates a governed space where:

project artifacts have structure
access is controlled
content has a lifecycle
AI agents can interact with the same artifact base through MCP
the work stays collaborative rather than disappearing into isolated prompt sessions

Migration knowledge belongs in the delivery asset base — governed, versioned, and built on over time.

Where this gets powerful: coding agents generating migration knowledge

One of the most immediately useful capabilities is letting coding agents analyze legacy source code and write the results back into the platform as structured artifacts.

That changes the shape of the work right away. Instead of running code analysis as a one-off exercise and pasting results into disconnected documents, the output becomes part of the migration workspace itself.

Those artifacts can capture:

business rules
architecture interpretation
functional requirements
non-functional requirements
migration risks
technical stack
interfaces
component boundaries
dependencies
assumptions and open questions

This is where the platform starts to earn its keep. It gives the migration program a way to turn raw source-code analysis into a governed, reusable knowledge base — which is a lot more valuable than treating AI output as temporary draft material floating around outside the project structure.

Why MCP matters in this model

The MCP layer is important because it lets AI clients work directly with project artifacts instead of only with copied context pasted into a prompt.

That means coding agents can:

read the current project knowledge
write new artifacts
update existing ones
work against a shared project context rather than an isolated prompt session

That makes the workflow more durable. Analysis doesn't disappear after one chat. It becomes part of the project memory — which matters a lot in migration programs, where the same concepts need to be revisited repeatedly across discovery, planning, target-state design, implementation, and validation.

The next step: agents reading the artifacts when building the new system

The real compounding effect comes when those same artifacts become usable context for building the new system — on top of whatever gets generated from the old one.

Once coding agents have helped document the business rules, architecture, requirements, risks, and technical constraints of the legacy system, they can use those same artifacts when supporting the design and implementation of the target system.

That's a meaningfully better workflow than asking an agent to generate target-state code or services from a thin prompt. Now the agent can work from a much richer base:

interpreted legacy behavior
captured business logic
validated requirements
explicit constraints
known migration risks
documented dependencies

That produces a more grounded design process. It also improves continuity between the current state and the future state — which is consistently one of the hardest parts of migration work to manage well.

Multi-agent orchestration is where this becomes scalable

Single-agent support is useful. But the more interesting direction — the one I think has the most leverage — is multi-agent orchestration on top of the artifact base.

Different agents can take on different roles:

one analyzes source code
one extracts business rules
one identifies technical dependencies
one drafts functional requirements
one focuses on non-functional requirements
one surfaces risks
one validates consistency across artifacts
one supports next-generation system design using the approved artifact set

At that point the platform becomes more than a repository. It becomes an execution layer for agent-assisted migration work.

Engineering teams and architects remain central. The platform reduces the volume of repetitive analysis and structuring work that normally slows them down.

Humans still matter — more, not less

The goal is better collaboration between people and agents — structured, continuous, and grounded in shared artifacts.

Humans still need to:

validate business meaning
make architectural trade-offs
challenge assumptions
prioritize risks
align stakeholders
decide what the target state should actually be

But agents can support that work by creating, refining, and reusing structured project artifacts. The model I find credible looks like this:

agents do more of the analysis and drafting
humans review and improve
agents use approved artifacts to support downstream work
teams collaborate around the same knowledge base

That's considerably stronger than using AI in isolated pockets.

Why this matters from an ROI perspective

The broader transformation discussion is relevant here too.

A lot of foundational transformation programs are hard to prioritize because the business case is too narrow — essentially reduced risk and lower cost — while the execution burden is high: complexity, uncertainty, poor documentation, hidden dependencies, fragmented knowledge. That combination is why these programs often feel like necessary evils.

What a platform like this actually delivers is a material improvement on the execution side:

more clarity, less ambiguity
more reusable knowledge
better continuity across phases
better leverage from AI systems
better collaboration between humans and agents

And when execution improves, the ROI conversation gets stronger. The program is no longer only about risk reduction or cost savings — it also starts delivering:

better speed
better readiness
more flexibility
more reusable capability for the next change cycle

Why we're building this now

We're building this platform because the migration delivery model itself needs to evolve.

The old model assumes humans manually reconstruct the current state; that teams rewrite knowledge again and again in different forms; that AI gets used opportunistically around the edges; that project context stays fragmented. Under that model, scale becomes a ceiling.

The emerging model looks different:

agents analyze the current state
artifacts become the shared unit of project knowledge
MCP exposes that knowledge to AI systems in a governed way
multi-agent workflows build on top of it
humans and agents collaborate continuously on the same artifact base
the same artifacts support both legacy understanding and target-state creation

That's the direction we think is worth investing in.

Final thought

Migration projects are context-management programs as much as they are technology programs. That's why tooling matters more than it sometimes gets credit for.

A team with unstructured knowledge will find that AI surfaces the problem faster, not fixes it.

But if the team has a workspace where knowledge can be captured as governed artifacts, enriched by coding agents, reused by downstream agents, and improved collaboratively by humans — the migration program starts to operate differently.

That's the reason we're building this platform — as a practical migration layer for teams doing difficult work under real delivery conditions, rather than a generic project tool or an AI demo.

Because if Generative AI is going to improve migration in a meaningful way, it needs more than prompts. It needs structure, context, and a place where humans and agents can do the work together.

Why we're building a migration platform for humans and coding agents

Agenda