The $2 billion migration consulting industry may be facing its biggest disruption yet. As AI agents become increasingly sophisticated, a critical question emerges: Can they handle large-scale code migrations and legacy refactoring at enterprise scale? This Platform Engineering community webinar tackled this question head-on, examining real-world case studies and the practical realities of agent-driven migrations.

Lou Bichard, Product Manager at Gitpod and former Principal Engineer of Developer Experience at DAZN, brought deep expertise to this discussion. At DAZN, he led the internal developer platform serving 13 million global users, giving him firsthand experience with the challenges of large-scale migrations. His current work at Gitpod, a platform for secure, standardized development environments used by 1.5 million users and large enterprises, positions him at the intersection of platform engineering and AI-driven automation.

If you missed the live session, you can watch the full webinar here and find a written recap below.

The AI innovations enabling migration at scale

Three key technological advances have made agent-driven migrations feasible. First, expanded context windows now allow models to process up to a million tokens, enabling agents to understand substantial portions of a codebase at once. While Gemini pioneered this capability in mid-2024, and Anthropic has followed suit, Lou cautioned that larger context windows don't automatically solve hallucination problems—they can sometimes introduce new challenges when too much information overwhelms the model.

Second, tool invocation has fundamentally changed what agents can do. As Lou explained, "The model itself can choose whether to actually answer your question to resolve the issue or it can even invoke one of the tools. And those tools can be literally anything." This capability allows agents to interact with command lines, logs, and source code, making them far more autonomous than simple code generators.

The third innovation is the maturation of reasoning models that can break down complex tasks into sequential steps, validate their work, and iterate based on feedback. This capability is essential for migrations, where agents must not only transform code but also verify that changes compile, pass tests, and meet quality standards.

"We have the building blocks," Lou stated. "I think the question around migrations is less is it possible but it's more of a question of which type of migrations can we do? How complex are those use cases?"

Four types of migration approaches

Lou broke down migration strategies into four distinct categories, each suited to different organizational needs and risk tolerances.

‍Deterministic or script-based migrations represent the traditional approach, using shell scripts or Abstract Syntax Trees (ASTs) to parse and transform code. While ASTs enable sophisticated syntax changes across large codebases, they require significant manual effort to write transformation rules. "Nine times out of 10 probably the migrations you want to run you're going to need to do some sort of custom scripting here and it could be quite a large investment," Lou noted.

‍Hybrid migrations combine deterministic scripts with LLMs, leveraging the strengths of both approaches. This is where Lou sees the biggest opportunity for most organizations today. By using ASTs to handle straightforward transformations and agents to tackle edge cases, teams can achieve higher success rates while maintaining control over the process.

‍Agent-based migrations rely entirely on LLMs to understand and transform code. While this approach offers maximum flexibility, it also requires careful prompt engineering and context management to achieve reliable results.

‍Blackbox migrations take a fundamentally different approach by observing a legacy system's inputs and outputs to derive specifications, then generating new implementations in modern languages. Lou characterized this as still being "a productized service" requiring significant consulting-style engagement. "There's still a lot of hands-on work that you have to do to understand your systems, to gather all this documentation, to traverse all these inputs," he explained.

Real-world case studies: Slack and Airbnb

Two particularly illuminating case studies came from Slack and Airbnb, which coincidentally tackled the same migration: converting from Enzyme to React Testing Library. This migration became necessary when Enzyme stopped supporting React 17, forcing organizations to update their entire test suites to upgrade to React 18.

Slack took a hybrid approach, combining AST transformations with LLM-based agents. They used ASTs to convert methods where possible, but when transformations failed or encountered edge cases, they fed the output back into agents to complete the work. This approach allowed them to achieve approximately 80% automation.

Airbnb pursued a more agent-centric strategy, breaking their migration into discrete, validated steps. "What they did that was unique and somewhat similar but a little bit more advanced than Slack is they really broke the migration down into those discrete steps," Lou explained. By ensuring the agent completed and validated each step—converting code, running tests, checking linting, verifying TypeScript compilation—before moving forward, Airbnb improved their success rate from 50% to 75%.

Both case studies revealed a consistent pattern: context engineering matters as much as prompt engineering. "Passing in the right files and passing in the right context is able to drive the agent success rate up," Lou emphasized. The right documentation, examples, and file selection can dramatically improve agent performance.

The anatomy of an effective migration agent

Lou broke down agents into four essential components, using OpenAI's framework as a reference point.

‍Instructions and context form the foundation. While we're familiar with prompt engineering, context engineering becomes critical for migrations. This means selecting the right files, providing relevant examples, and including migration documentation. "One of the most important parts is actually making sure that your agent, your LLM that's actually doing the processing has the right context," Lou stressed.

‍The model itself varies in capabilities, some excel at reasoning, others offer larger context windows, and they differ in cost and security features. The choice depends on your specific migration needs and constraints.

‍Tools enable agents to interact with the outside world. In Slack's case, tools included their test suite, linting, and TypeScript compilation. "They broke down their migration into individual steps which meant that they were able to do those individual code transformations but then also validate by running their test suite," Lou explained. This validation loop allows agents to iterate and improve their output.

‍Runtime determines where and how agents execute. You can run migrations locally on individual machines, which works well for testing feasibility, or use orchestrated systems that can process multiple repositories in parallel. "There are a new category of tools that now can run these migrations at scale inside of your organization," Lou noted, pointing to platforms that can coordinate agent work across hundreds or thousands of repositories.

The critical role of human-in-the-loop

Perhaps the most important insight from the webinar was the non-negotiable need for human review. "There is no form of migration that I am seeing that is of any significant complexity that can be done without a human in the loop," Lou stated emphatically.

The 80/20 rule emerged consistently across case studies. Agents can typically automate 80% of a migration, but the final 20% requires human expertise. "There is an asymptote and there is diminishing returns for fine-tuning that last sort of 20% of a migration," Lou explained. "However, at scale, achieving that 80%, that initial 80% of a migration can be significantly valuable."

Interestingly, while agents reduce investigation and development time, they shift the burden to testing and verification. "The best thing that agents are good at doing today is writing code," Lou acknowledged. "However, what that does mean is that there is still a shift in burden then to testing and verification."

To make human review effective, organizations must avoid isolating engineers from the migration process. Lou highlighted Google's approach: "Their toolkit also aims to assist engineers and let them focus on complex aspects but without isolating them from the process." This means sharing the agent's reasoning through commit history, documentation, or exposing developers to the chat context that guided the migration.

When does agent-driven migration make sense?

Lou provided practical guidance on when organizations should invest in agent-driven migrations. The break-even point typically occurs around 100 to 500 engineers, the same threshold where platform teams become valuable. "There does come a point around about 10 teams, 100 to 500 engineers which is actually interestingly the same number we see for platform teams when it's the time to invest in internal enablement teams," he noted.

For smaller organizations, the setup cost of building migration infrastructure may not justify the investment. Manual migrations or simple scripts might be more efficient. But for larger organizations, the ROI becomes compelling. "Most of these types of migrations in a lot of organizations would be measured in months if not in years," Lou explained. "If you can raise that PR that's 80% done, you can significantly reduce the timelines."

Local migrations offer a low-cost entry point. You can download your favorite agent (Cursor, Claude, etc.) and experiment with migrations on individual repositories to test feasibility. Once you've validated the approach and refined your prompts and context, you can consider orchestrated solutions that scale across your entire codebase.

Key metrics to track include time to merge PRs, number of commits required after the initial migration PR, and how quickly teams can integrate the changes. These indicators reveal how well your migration approach is working and whether scaling makes sense.

The future of migration consulting

Lou's perspective on the industry's future was nuanced. "I think what we will see is consultants will shift to this more like blackbox migrations where there's a heavy amount of sort of white glove and human in the loop that's required," he predicted. Meanwhile, hybrid migrations will increasingly move in-house as organizations build internal capabilities.

He drew a parallel to how CI/CD became standard infrastructure: "You join a company or organization today we expect there to be version control, we expect there to be continuous integration." Similarly, he believes the ability to enact code changes automatically across an entire estate will become commonplace. "I do believe that what we'll see in the future is all organizations having this ability to enact code changes across their estate by doing so automatically will become much more commonplace."

However, this doesn't mean migrations become fully autonomous. "Migrations do require human in the loop. You need a human reviewer to review them. There is not a version of migrations that exists today where that's not possible," Lou emphasized. The goal is to reach 80% automation while accepting that the final 20% requires human expertise.

Key takeaways

Hybrid migrations offer the best opportunity for most organizations today. By combining deterministic scripts with AI agents, you can achieve higher success rates while maintaining control. The tools that Slack and Airbnb used are available to any organization—no proprietary technology required.

‍Context engineering is as important as prompt engineering. Success depends on providing agents with the right files, examples, and documentation. Investing time in refining what context you provide to agents can dramatically improve their performance and your migration success rate.

‍Plan for 80% automation, not 100%. Accept that agents will handle the bulk of the work, but human review remains essential for edge cases, security considerations, and final validation. Don't isolate engineers from the process—expose them to how the migration happened to speed up review and maintain code quality.

‍Start small and scale gradually. Test migrations on individual repositories first to establish baselines and refine your approach. Track metrics like time to merge and commits required post-migration to gauge effectiveness before scaling to your entire codebase.

‍The break-even point is around 100-500 engineers. Smaller organizations may find manual migrations more efficient, while larger organizations can achieve significant ROI through agent-driven approaches. Consider both local and orchestrated solutions depending on your scale and needs.

Join the Platform Engineering community and connect with peers on Slack and stay tuned for more events.