How a global pharmaceutical company is using Ona to automate 95% of their GitLab to GitHub migration

A top-500 global pharmaceutical company is migrating tens of thousands of repositories from GitLab to GitHub. Their platform engineering team is using Ona to build a self-serve migration path that automates the full process: code, merge requests, project history, and CI pipeline conversion, at 90-95% automation.

Key outcomes:

1. 90-95% automated migration — Code, merge requests, issues, and CI pipelines handled automatically.
2. Self-serve migration at scale — A developer portal integration lets any team migrate their own repos on their own terms.
3. GitLab CI to GitHub Actions conversion — Ona reads the existing pipeline, understands what each job does, and translates it into idiomatic GitHub Actions.
4. PR-based review — Nothing merges without a human reviewing the PR. Teams stay in control of what ships.

The challenge

The company is consolidating all source code management on GitHub. About 70% of the organization's repositories are on GitLab: tens of thousands of repos spanning hundreds of teams.

The migration is a big undertaking for a few reasons.

Technically, each repository carries its own CI pipelines, issue history, and cross-repository dependencies. Some repos span multiple languages. Others have deep integrations that don't migrate cleanly. A systems integrator has been brought in to run the bulk migration over a three-year timeline, targeting roughly 60% automation for code pipeline conversions. The rest would be manual.

Commercially, the company's GitLab contract is coming up for renewal. Every repo migrated before that renewal strengthens their negotiating position. The systems integrator is paid on milestones, not time and materials, so they're financially motivated to move fast too. Speed of migration translates directly to cost savings.

Culturally, the organization is deeply decentralized. Engineering decisions are rarely mandated from the top. Platform teams offer tools and services, and adoption spreads as teams discover what works. So migrating tens of thousands of repos isn't just a technical problem or a business problem. It's an adoption problem: you can't force hundreds of teams to move on your timeline.

The platform engineering team is taking a different approach.

The solution: a self-serve migration powered by Ona

Instead of waiting for a centralized migration to reach every team, the platform engineering team is partnering with Ona to build a self-serve migration path: let any team migrate their own repositories, whenever they're ready.

The solution is a single button on the company's internal developer portal. An engineer selects their GitLab repository, clicks "migrate," and an Ona automation does the rest.

What happens when the button is pressed:

1. Ona verifies access to both GitLab and GitHub, checking tokens and CLI tooling are in place
2. The full codebase is migrated to a new private GitHub repository, including code, merge requests, and project history
3. Ona converts the CI pipeline from GitLab CI to GitHub Actions. It reads the pipeline configuration, understands what each job does, and translates it into idiomatic GitHub Actions, deciding whether each job should become a "step" or a separate "job" based on its purpose and dependencies
4. The new pipeline is validated and linted to make sure it behaves the same as the original
5. Ona opens a pull request with all the changes for the engineer to review

The whole migration runs without human intervention. But nothing merges without a human reviewing the PR first, so teams stay in control of what lands in their codebase.

In early testing, 90-95% of the migration is automated. Engineers review the PR, do the final push, and they're done.

Why this matters for enterprise migrations

This is structurally a new way to perform migrations, not a script or a one-off tool. Ona works from the pipeline specification to the actual migration, converting CI configurations, validating the output, and iterating until builds and tests pass. It opens a PR for review when the work is done and it can do this across dozens of repositories concurrently.

This is organizational-scale work that can't be solved one developer at a time. A code assistant can help one engineer refactor one file. Migrating tens of thousands of repositories requires something that works autonomously across your entire codebase, doing the repetitive, high-volume engineering work that would otherwise take a dedicated team months.

The systems integrator estimated roughly 60% automation for the code pipeline portion of their migration. In early testing, the Ona-powered self-serve path hit 90-95%, and the scope is broader: code, merge requests, issues, and CI pipeline conversion handled together.

The business impact goes beyond engineering hours. Every repo migrated through the self-serve path is one less repo in the bulk migration backlog, which means faster overall completion. Faster migration directly improves the company's position heading into an upcoming contract renewal with their existing SCM provider. The faster teams migrate, the less they pay for infrastructure they're moving off of.

The adoption flywheel

No one at the company is being told they have to use the self-serve migration. The button is there on the developer portal. When the alternative is a manual migration that takes days or weeks, teams actively want to use it. Early adopters tell their colleagues, and it spreads. Most large enterprises face the same challenge with any platform migration: the technology might be ready, but getting thousands of engineers to actually move is the hard part. A self-serve approach that's easier than the manual alternative leads to more natural adoption.

What's next

The self-serve migration is rolling out across the organization. As more repositories move to GitHub, the platform engineering team is tracking automation rates at scale, cataloging edge cases, and working on automations to handle the migration in bulk vs. self-serve.

The project is implemented using Ona's Enterprise solution, deployed inside the customer's own AWS environment. Built on AWS services including Bedrock, the architecture gives the platform engineering team full control over where their code and data live, a requirement for a company of this size and regulatory profile. Ona runs entirely within the customer's VPC, meaning source code never leaves their infrastructure. The composability of AWS is key to making this work: Ona can plug into the customer's existing toolchain and scale compute resources up or down as migration volume changes. During peak migration periods, Ona processes dozens of repositories concurrently. The same infrastructure that powers a single repo migration scales to handle thousands.