We migrated 4,200 repos to GitHub Enterprise. Here's what I'd do differently.

Two years after orchestrating the migration of 4,200 repositories to GitHub Enterprise, here’s what I carry forward.

What we got right

The decision to migrate in batches of 50 repos rather than all at once saved the project. Each wave gave us a 48-hour feedback loop before moving on.

Automating CI pipeline validation after each migration was non-negotiable. Without it, we would have discovered regressions in production.

What we missed

We underestimated the cognitive load on teams. Migrating a repo isn’t just a click: you need to update tokens, reconfigure webhooks, train developers on new branching conventions.

Communicating “when it’s done” isn’t enough. Teams need a planned migration window, not a surprise in their backlog on a Monday morning.

The playbook I wish I’d had

1. Map inter-repo dependencies before migrating. Pipelines that pull artifacts from other repos are time bombs.
2. Create a dedicated Slack channel per wave, not a global one. Questions are contextual.
3. Measure velocity before and after. Not to justify the migration — to detect teams that fell behind.
4. Plan for 20% edge cases. Monorepos, private forks, legacy third-party integrations.

The migration itself is the easy part. The real work is changing habits.