Cross-repo migration agents

Cross-repo migration agents are AI agents configured to execute a consistent modernization task across dozens or hundreds of repositories simultaneously, opening PRs in each, handling each repository's individual edge cases, and tracking progress across the fleet. Where single-repository migration agents handle depth (one complex migration thoroughly), cross-repo agents handle breadth (one consistent migration applied uniformly across all relevant repositories).

The classic use case is organizational standardization: an internal API changes its authentication method, and 40 microservices need to update their client configuration. A new logging standard is adopted, and all 30 backend services must migrate from the old library to the new one. A security vulnerability is found in a common utility class, and the patched version must be deployed across every repository that imports it. Without cross-repo agents, each of these becomes a coordination effort that takes weeks of distributed work across multiple teams. With cross-repo agents, the same change is applied uniformly in hours.

The agent runs with a script or task specification that defines: what repositories are in scope, what transformation to apply, how to validate success, and how to handle failures. The agent clones each repository (or works from cached state), applies the transformation, runs the tests, and opens a PR. For large fleets (100+ repositories), the agent runs in parallel across batches of repositories. Each PR is independent - a failure in one repository does not block progress in others. The team reviews and merges each PR on its own timeline.

Cross-repo agents are the mechanism by which organizational consistency norms can actually be enforced rather than aspirationally maintained. Every time a standard changes, a cross-repo agent can propagate the change to every repository that needs it. The gap between "we have a standard" and "all repositories comply with the standard" shrinks from months to days.

August 2026 is when this stopped being a projection. Gergely Orosz's survey of the migration story (August 20) calls migrations the unlock nobody predicted, and the load-bearing example is Asana's Enzyme test-framework migration, completed in two weeks - work that, in his words, "would surely have been kicked down the road." The same pattern shows up at Airbnb and Uber. The important part is not the fourteen days. It is what that number does to a category of work that used to be permanently deferred by arithmetic: a migration that costs one engineer-quarter never wins against a roadmap, so it is postponed indefinitely and quietly becomes a constraint on everything built afterwards. At two weeks, that calculation inverts, and the migration backlog turns from a fact of life into a set of decisions somebody is actively making. Armin Ronacher's "Fast and Hard Code" (August 22) extends the same logic sideways: language familiarity has stopped gating language choice, which reopens targets that were previously off the table for want of in-house specialists - for better and worse.

The practical corollary is that the constraint moves from execution to review. If forty repositories receive a mechanically correct PR on the same afternoon, the fleet is no longer bounded by how fast the agent works but by how fast forty teams absorb the change - which is a coordination problem you have created rather than solved, unless you plan for it.

• Eliminates consistency drift across repositories - In organizations with many repositories, standards drift is the default; cross-repo agents make propagating standard changes as easy as making them in one repository
• Reduces the coordination tax on platform teams - Platform teams that own shared standards typically spend disproportionate time coordinating standard migrations across teams; cross-repo agents remove the manual coordination and let each team simply review and merge their PR
• Makes security patches instantaneous at scale - When a vulnerable dependency is patched, a cross-repo agent can open PRs across all affected repositories within hours; the organization's CVE remediation time drops from weeks to days
• Enables large-scale architectural decisions - Architecture decisions that would have been prohibitively expensive to enforce (because they require changes to every repository) become viable at agent-level speed and cost
• Creates an audit trail for compliance - Every cross-repo migration produces a complete record: which repositories were targeted, what was changed, which PRs were opened, which were merged, which failed and why. This audit trail is valuable for security compliance and architectural governance.

1. Identify your first cross-repo migration candidate - Choose a high-value, low-risk change that affects many repositories: a common dependency version bump, a logging configuration standardization, or a shared utility class update. Low-risk means: the transformation is mechanical, the change is small, and tests will catch regressions.
2. Build a repository inventory with metadata - You need a machine-readable list of all repositories with metadata: language/framework, which shared dependencies they use, team ownership, and CI status. This inventory is the agent's targeting system for cross-repo work.
3. Write and test the migration script on one repository - Before running the agent at scale, validate the transformation on a single repository manually. Confirm it produces the expected output, passes tests, and opens a clean PR. The single-repo validation catches problems before they multiply across 40 repositories.
4. Configure parallel execution with rate limiting - Run the agent on batches of 5-10 repositories in parallel, not all simultaneously. Rate limiting prevents CI system overload and gives reviewers a manageable PR flow rather than 40 PRs opening in the same minute.
5. Set up cross-repo progress tracking - Maintain a tracking document (or database table) that records each repository's migration status: not started, in progress, PR open, PR merged, failed. This is the agent's state management and your progress dashboard.
6. Establish escalation criteria - Define what causes the agent to stop and escalate: test failures it cannot fix, merge conflicts with active feature work, repositories with no CI configuration, protected branches that require additional approvals. These criteria prevent the agent from spending time on repositories that need human attention.
7. Name a human owner on every PR the agent opens - LinearB's 2026 benchmark data across 8.1M pull requests found agent-opened PRs without a named human accountable for landing them merging at markedly lower rates: 79% for elite organizations, 58% for good and 37% for fair, against overall 30-day merge rates of 90/86/81%. Ownership is the variable that explains the gap. Assign it in the mechanism that opens the PR rather than hoping a team picks it up.
8. Have the agent emit a reviewable shape, not one large diff - A migration that touches a data model, an API, an integration and a UI should arrive as a stack of dependent branches, each independently reviewable, rather than as a single thousand-line PR. Zalando's teams found PR sizes ballooning under agent authorship until they negotiated explicit size limits; deciding the shape up front is cheaper than renegotiating it after forty teams have complained.

Not having team buy-in before opening PRs. A cross-repo agent that opens PRs without advance notice creates confusion and resistance: developers open their repository dashboard to find 3 PRs from an agent they did not know existed. Brief team leads before running a cross-repo migration; explain what the agent is doing and why.

Insufficient error handling across diverse repositories. A fleet of 40 repositories will have 40 slightly different build configurations, dependency management approaches, and project structures. The agent must handle structural variation gracefully - skipping repositories it cannot process rather than failing noisily.

Letting failed PRs accumulate without triage. When the agent fails in 5 of 40 repositories, those 5 failures need human triage. Establish a clear owner for cross-repo migration failures and a timeline for triage. Failed migrations that are not triaged within a week are candidates for manual handling.

Running cross-repo migrations during active feature sprints. A cross-repo migration that opens PRs in all repositories simultaneously competes with feature PRs for review attention in every team. Schedule large cross-repo migrations for low-activity periods: early in a sprint, before a sprint planning session, or on a team rotation where one team handles reviews.

Treating a cheap migration as a free one. Once a two-week migration is genuinely achievable, the temptation is to run every deferred item on the list, and the execution cost is no longer what limits you. Review attention is, and it is spread across every team receiving a PR. A backlog that is a choice rather than a constraint still has to be sequenced like one: pick the migrations whose value justifies the review load they impose on other people, and say no to the rest deliberately rather than by running out of capacity halfway through.

No post-merge monitoring. A cross-repo migration that is merged successfully in all 40 repositories but causes a production issue in 3 of them requires a post-merge monitoring period. Define a monitoring window (48-72 hours) and watch for increased error rates or deployment failures in the migrated services.