Why your migration tools are failing your engineers

You have a migration to complete. The scope is defined, the target state is agreed on, and the team is resourced. But six months in, you are still not done. Estimates keep slipping. Engineers are burning time on investigation instead of implementation. Every change uncovers something nobody knew was there.

The tools are not keeping up. Here is why.

The search problem nobody talks about

Most engineering teams think of code search as a solved problem. You have an IDE. You have grep. You have GitHub's search bar. What else do you need?

Quite a bit, once your codebase reaches a certain size.

Keyword search finds strings. It does not understand what the code does, how components relate to each other, or what will break when you change something. You can search for a function name and get two thousand results. Figuring out which ones are relevant still requires a human to read them all.

This is the invisible tax on every large-scale migration: the investigation time before the work even starts. An engineer trying to understand the scope of a framework migration is not writing code for hours or days. They are reading code. Tracing call chains. Following imports across repositories. Building a mental model of something too large to hold in their head.

And then they make a change, and something breaks in a repo they did not think to check.

Multi-repo makes everything harder

Most migration tooling was built for single-repo environments. The assumption is that your code lives in one place and your tools can see all of it.

Modern engineering organizations are rarely that simple. Acquisitions bring in repositories from different companies. Platform teams split services into their own repos. Some code lives in a legacy version control system like Perforce while newer code lives in Git. The result is a distributed codebase where no single tool has full visibility.

When your search only works in one version control system, your developers make decisions without seeing the full picture. When your static analysis tool does not cross repository boundaries, your dependency maps are incomplete. When your AI coding assistant loads only local files for context, it gives confident suggestions that break things elsewhere.

MathWorks experienced this directly. Their engineering team spans Perforce, GitHub, and GitLab, with a codebase built over forty-plus years. Their homegrown search tool only worked within Perforce. Engineers working in other systems, or trying to understand cross-system dependencies, were working partially blind.

AI agents amplify the problem before they solve it

Engineering teams are increasingly deploying AI coding agents to accelerate migration work. Agents can generate boilerplate, translate between frameworks, and apply repetitive transformations at speed.

But agents have the same visibility problem human engineers do, and sometimes worse.

A human engineer who has been on the team for three years has internalized a lot of context about the codebase. They know which modules are fragile. They know the implicit dependencies that do not show up in the import graph. An AI agent starting from scratch has none of that. It has whatever fits in its context window.

Sourcegraph's CodeScaleBench evaluated coding agents on tasks drawn from real enterprise codebases: 370 tasks across 40-plus repositories, spanning debugging, security, multi-repo coordination, and organizational-level queries. Without code intelligence tools, agents running on Kubernetes-scale systems timed out after two hours. With access to Sourcegraph's MCP tools, the same tasks completed in 89 seconds.

The difference is not model capability. The difference is what the model can see.

On retrieval tasks, agents without code intelligence retrieved the right files 12.7% of the time. With Sourcegraph MCP, that number climbed to 27.7%. On organizational queries spanning multiple repositories, precision at rank 5 went from 0.7% to 47.1%.

When an agent cannot find the relevant code, it either gives up or makes things up. Both outcomes are expensive.

The cost compounds at scale

These problems do not stay small. A migration that takes twice as long as expected does not just cost twice as much in engineering time. It delays dependent projects. It extends the period during which your team is maintaining both old and new systems simultaneously. It increases the risk that the migration never fully completes, leaving you with a permanently split architecture that nobody planned for.

The teams with the largest, most complex codebases are the ones most in need of migration. They are also the ones most likely to have their migrations stall, because their tools were not built for the scale they are operating at.

What "fixed" looks like

The migration problem is not fundamentally a people problem or a process problem. It is a visibility problem. Engineers and agents make better decisions when they can see what they are working with.

Code Intelligence that works across repositories, version control systems, and languages gives teams the foundation they need to plan migrations accurately, execute them confidently, and know when they are actually done.

That is the difference between a migration that ships and one that becomes a permanent item on the backlog.

---

Sourcegraph provides cross-repo Code Intelligence for teams managing large, complex codebases. See how engineering teams are completing migrations faster with better visibility into their code.