10,000+ repositories to GitHub Enterprise Cloud

A self-hosted GitHub Enterprise Server is a product the company has to run: every upgrade, every integration, every outage, and the infrastructure under all of it. That cost of maintenance was the first reason to move.

The second was capability. GitHub ships its AI-first features to the cloud product first, and a server install puts a ceiling on what a platform team can offer its engineers. At The Hartford that ceiling sat over 10,000+ repositories and the CI/CD toolchain wired to them. Moving was the prerequisite for the developer platform that followed.

The company is a regulated insurer, so access, audit and retention requirements came with every repository, not just the sensitive ones. Secrets that had found their way into repositories over the years set hard cutover deadlines, agreed with the security team, that the plan had to meet.

Thousands of engineers could not stop shipping for a migration. Pipelines across Jenkins, Harness, AWS CodePipeline and the rest of the toolchain pointed at the old host and had to keep working through the move, which meant the two platforms had to coexist cleanly for as long as the program ran.

Repositories moved in waves ordered by impact: the least-referenced ones first, the ones everything else depended on last. That proved the integrations on low-stakes repositories before the high-stakes ones moved, and it kept each hard deadline survivable.

GitHub's own importer did the moving, wrapped in custom scripts that fit it to the enterprise's organization, team and permission model. A contracted vendor executed the migration itself and was accountable for it end to end. The scope was active repositories; whether an inactive one was archived instead was left to the application team that owned it, and few were.

I led the program. The hardest part, and the part my engineers owned, was not moving repositories. GitHub Enterprise Server had more than fifty integration points: the CI/CD toolchain, Ansible, Azure DevOps, Plutora, Prisma Cloud, security scanning, an internal release-gating framework, and more. Every one had to be designed to work against both Server and Cloud while the waves ran, then cut over cleanly once the last wave landed.

Not all fifty were known on day one. Usage analysis across the platforms kept surfacing pipelines that teams had built ad hoc, outside the program's knowledge or scope, each one a cutover nobody had planned for. For the length of the migration the inventory lived in a spreadsheet, updated by hand every day.

Planning took its time. The execution, from the first wave to the last, ran in under twelve months.

The company's code lives on GitHub Enterprise Cloud. The self-hosted install and its maintenance are gone, and the rest of GitHub's roadmap, Copilot and the AI-first tooling included, is now something the platform can offer rather than wait for.

The migration is the foundation the developer platform stands on: the single pane of glass used by 4,000+ engineers tracks 13,000+ repositories today, a number that only exists because they are all in one place.

And that daily spreadsheet is the origin of the DevOps intelligence work in the ATLAS case study. Discovering pipelines by accident, one usage report at a time, is what made the case for real-time pipeline monitoring, compliance and discoverability as a platform capability rather than a migration chore.

Order the waves by blast radius, not by convenience. Moving the quiet repositories first buys you the evidence you need before the loud ones move.

The migration is the easy part. Count the integration points before you plan anything else, assume the count is wrong, and budget for the period when both platforms are live, because that is where the engineering is.

Let a hard deadline do some of the work. The secrets cutover dates were a constraint, and they were also the thing that kept the program from drifting.