Tools to automate org-wide refactors: open and track PRs across hundreds of repos with approvals and progress tracking

Org-wide refactors sound simple on paper—“just update this pattern everywhere”—but in a real enterprise codebase, they’re anything but. You’re dealing with hundreds or thousands of repositories across GitHub, GitLab, Bitbucket, Gerrit, or Perforce; different teams and ownership models; strict review rules; and the need to prove progress to stakeholders. The bottleneck usually isn’t writing the patch. It’s opening consistent PRs across all those repos, routing them to the right reviewers, and tracking approvals and merges without living in a spreadsheet.

In this guide, I’ll rank the main categories of tools that can help automate org-wide refactors—specifically focusing on opening and tracking PRs across hundreds of repos with approvals and progress tracking. I’ll also show where Sourcegraph Batch Changes fits when your goal is repeatable, auditable change at scale.

Quick Answer: The best overall choice for orchestrating org-wide refactors across many code hosts, with automated PR creation and tracking, is Sourcegraph Batch Changes. If your priority is tight integration with a single Git hosting platform (especially GitHub) and you’re okay with some scripting, native platform automation (GitHub Actions / GitLab CI + scripts) is often a strong fit. For highly customized, in-house workflows where you already have a strong platform engineering function, consider bespoke internal migration tools built on APIs and bots.

---

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Sourcegraph Batch Changes	Cross-repo refactors across many code hosts with full PR lifecycle tracking	Declarative, multi-repo PR automation plus unified progress view	Requires adopting Sourcegraph as a platform
2	Native platform automation (GitHub / GitLab, etc.)	Teams living in a single code host who can script their own migration logic	Deep integration with one platform’s PR/review model	Harder to scale across multiple hosts and keep consistent tracking
3	Bespoke internal migration tools	Orgs with strong platform teams and very specific workflows	Fully customizable to your policies and edge cases	High build/maintenance cost; brittle over time

---

Comparison Criteria

We evaluated each approach against the realities of org-wide refactors:

• Scale & universality: How well does it handle 100–1,000+ repositories, multiple code hosts (GitHub, GitLab, Bitbucket, Gerrit, Perforce), and billions of lines of code without falling apart?

• PR automation & lifecycle tracking: How easy is it to open, update, and close PRs across all repos, enforce approvals, and track progress from “no PR yet” through merged?

• Governance & enterprise fit: Does it respect existing permissions and review workflows (SSO, RBAC, branch protections), and can you audit what changed and why?

---

Detailed Breakdown

1. Sourcegraph Batch Changes (Best overall for multi-repo, multi-host refactors with tracking)

Sourcegraph Batch Changes ranks as the top choice because it’s built specifically to search, change, and track code across all your repositories and code hosts—from one place—while giving you an auditable view of every changeset from creation through merge.

Unlike ad-hoc scripts, Batch Changes sits on top of a universal code understanding platform. It leverages the same engine that powers Sourcegraph’s Deep Search and Code Search, so you can reliably find every usage you need to update, then turn that understanding into coordinated, multi-repo PRs.

What it does well:

• Declarative, org-wide PR creation and management:
  You define your refactor once in a declarative spec (what to change, where, and how). Batch Changes then:

  • Finds matching code across all supported code hosts (GitHub, GitLab, Bitbucket, Gerrit, Perforce and more).
  • Generates patches for every affected repo.
  • Opens PRs/MRs/changesets for each repository automatically.
  • Keeps a single UI where you can see the status of every changeset: open, failed checks, approved, merged, or closed.

  This is the difference between “we have a script” and “we have a first-class workflow with visibility and control.”

• Cross-codebase scope without losing control:
  Batch Changes is built for enterprise-scale code: 100 or 1M repositories, billions of lines of code. It:

  • Works across all your code hosts instead of forcing you to centralize everything first.
  • Respects existing branch protections, approvals, and CI checks.
  • Lets each repo’s owning team review and merge on their own schedule, while you still have a global dashboard for the overall migration.

  You get a single migration campaign, not a pile of uncoordinated PRs.

• Progress tracking, governance, and insights:
  Beyond “are the PRs open?”, you get:

  • A unified view of all changesets: filter by state, code host, repo, or owner.
  • Visibility into which teams are blocking, which PRs have failing checks, and where the migration is stuck.
  • Integration with Insights to build dashboards showing migration coverage over time and refactor completion across key repository sets.

  For regulated or high-stakes environments, you also get:

  • SOC2 Type II + ISO27001 compliance.
  • SSO support with SAML, OpenID Connect, and OAuth.
  • SCIM for user management and RBAC for granular access control.
  • Zero data retention for LLM inference, so code context for AI agents is not persisted beyond what’s required.

Tradeoffs & Limitations:

• Requires Sourcegraph as a platform:
  Batch Changes assumes you have (or are willing to adopt) Sourcegraph as your code understanding layer. If you’re only looking for a one-off migration in a small org with a single GitHub org, that might feel like more infrastructure than you want. But if you’re already dealing with multi-repo sprawl, that platform layer quickly becomes core infrastructure rather than overhead.

Decision Trigger:
Choose Sourcegraph Batch Changes if you want a repeatable way to run org-wide refactors—across many repos and code hosts—with automated PR creation, consistent approvals, and a single place to track progress through to merge.

---

2. Native platform automation (Best for single-host teams deeply tied to GitHub/GitLab)

Using native platform automation—GitHub Actions plus the GitHub API, GitLab CI plus GitLab’s API, or similar—can be effective when your world is mostly inside one code host and your platform team is comfortable scripting.

Here, you typically:

• Write a script or tool (often in Go, Python, or TypeScript) that:
  • Enumerates repositories via the host’s API.
  • Clones each repo or applies changes via a REST/GraphQL API.
  • Creates branches, commits the refactor, and opens PRs/MRs.
• Run that script via CI (GitHub Actions workflow, GitLab pipeline) or an internal automation framework.
• Track progress using labels, project boards, or external dashboards.

What it does well:

• Deep integration with one code host:
  You’re using the same primitives your developers already use every day:

  • Native PR/MR templates.
  • Reviewers, teams, and CODEOWNERS.
  • Branch protections and required status checks.

  This means zero learning curve for reviewers. Everything shows up in the UI they already use.

• Flexible, scriptable workflows for smaller scopes:
  For smaller migrations (dozens of repos) or single-team refactors, you can:

  • Stand up a custom script quickly.
  • Hard-code some assumptions about repo layout and build tools.
  • Use labels or projects to track PR states.

  With a single host and homogeneous tech stack, this can work well.

Tradeoffs & Limitations:

• Limited cross-host support and poor global visibility:
  As soon as you add more code hosts—GitHub + Perforce, GitLab + Gerrit—it gets messy:

  • Each host requires its own scripts, auth model, and API quirks.
  • You end up with siloed progress tracking and no single view of “this migration across the entire org.”

  Even on a single host, tracking state across hundreds of PRs with project boards or labels is fragile. It’s easy to lose track of which PRs were superseded, abandoned, or blocked by CI.

• Brittle maintenance burden over time:
  Over multiple migrations, these scripts:

  • Accumulate conditionals for edge cases and special repos.
  • Depend on APIs that can change.
  • Require manual updates for new repos, orgs, or product lines.

  You’ve effectively built an internal migration platform without the guardrails and governance of a dedicated tool.

Decision Trigger:
Choose native platform automation if you’re mostly in a single code host, have an ops or platform team that’s comfortable owning custom scripts, and your refactors don’t need to span multiple hosting platforms or millions of lines of legacy code. It’s strongest when you want tight integration and are okay trading off some robustness and visibility.

---

3. Bespoke internal migration tools (Best for highly customized, in-house workflows)

Some organizations build bespoke internal migration tools—internal web apps or CLIs—in front of the underlying Git host APIs. These tools typically:

• Provide a UI for choosing a migration “recipe.”
• Apply codemods or templates across configured repositories.
• Open PRs using service accounts or bots.
• Integrate with internal systems: change management, ticketing, or approval workflows.

This is the “roll your own Batch Changes” path. I’ve seen versions of this in large banks, telcos, and regulated environments where change governance is unusually complex.

What it does well:

• Highly customized workflows and policy integration:
  You can embed exactly the controls you need:

  • Enforce internal change policy, approvals, and risk classifications.
  • Integrate with your CMDB, ticketing system, or internal inventory.
  • Encode special-case behavior for legacy monorepos or Perforce depots.

  For environments where policy is as important as code, this control can be appealing.

• Tailored visibility aligned to your org structure:
  You can:

  • Group migrations by business unit or product line.
  • Roll up progress by risk classification or regulatory domain.
  • Wire alerts into whatever notification stack you use.

Tradeoffs & Limitations:

• Significant build and maintenance cost:
  You’re not just writing a script. You’re building and running a platform:

  • UI, backend, database, auth integration (SAML/OIDC), RBAC.
  • Per-host integration (GitHub, GitLab, Bitbucket, Perforce, Gerrit).
  • Ongoing maintenance when APIs change or new code hosts come online.

  This cost compounds. Especially when you factor in security reviews, audits, and upgrades.

• Harder to keep pace with AI-driven code growth:
  As AI accelerates code creation, the set of migrations you “must” run grows. If your migration platform can’t:

  • Understand the full codebase reliably.
  • Integrate with agentic workflows.
  • Scale to billions of lines without manual tuning.

  It becomes another bottleneck instead of a force multiplier.

Decision Trigger:
Choose bespoke internal migration tools only if you already have a strong platform engineering organization, your governance needs are extremely specific, and you’re prepared to invest in a multi-year internal product. Even then, consider using a code understanding platform like Sourcegraph as the backbone, instead of re-implementing search, navigation, and cross-host orchestration from scratch.

---

Final Verdict

When your goal is to automate org-wide refactors and reliably open and track PRs across hundreds (or thousands) of repositories—with real approvals and progress tracking—the core question is: do you want a one-off script, or a repeatable platform?

• If you need cross-host scale, a unified dashboard, and enterprise-grade governance, Sourcegraph Batch Changes is the best overall fit. It gives you:

  • Universal code search and Deep Search to find every place you need to change.
  • Declarative, multi-repo PR creation across GitHub, GitLab, Bitbucket, Gerrit, Perforce, and more.
  • A single UI to track changesets from creation through checks, reviews, and merge.
  • Enterprise controls (SAML/OIDC/OAuth SSO, SCIM, RBAC, SOC2 Type II + ISO27001, zero data retention) that align with how you already manage access and risk.

• If you’re all-in on a single code host and comfortable owning scripts, native automation can work—just recognize the limits around multi-host expansions and long-term maintenance.

• If you’re considering a bespoke migration platform, treat that as a strategic product decision. It may still make sense to plug into a code understanding platform like Sourcegraph rather than reinvent the foundations.

The organizations that handle AI-driven code growth well are the ones that treat “change across the entire codebase” as an intentional capability—not an ad-hoc project. They give both humans and agents the same powerful search, understanding, and automation layer, and they wire it into their governance model from day one.

---

Next Step

Get Started