GitLab to GitHub migration, plus Bitbucket, Azure DevOps, Jenkins and CodeCommit.

How do you migrate from GitLab to GitHub?

Mirror the repositories, or use GitHub Enterprise Importer, the official GitLab to GitHub migration tool, if you want merge requests and issues too. Since 3 August 2026 GEI migrations from GitLab.com and maintained GitLab Self-Managed versions are generally available through the gh gl2gh extension, into Enterprise Cloud organisations on github.com or ghe.com. GitHub Enterprise Server is not a supported target from GitLab.

What GEI brings from GitLab: Git history and the project wiki, commit comments, issues with comments and milestone events, merge requests as pull requests with reviewers, approvers and state events, milestones, releases and release assets, reactions, uploads, and members as mannequins. Merge request comments land as review comments only when diff data is present; otherwise they become flat comments.

What it leaves behind:

• LFS objects (push them separately), CI/CD pipelines and schedules, CI/CD variables, webhooks, job logs and artifacts.
• Repository policies: required approvals, merge trains, pipeline gates, mirroring settings. Group settings and membership.
• Snippets, issue boards, time tracking, design management and vulnerability reports.

Size limits: 40 GiB of Git data per repository (in public preview), 400 MiB per file during migration and 100 MiB after, and a 40 GB limit on the export archive on GitLab.com (self-managed instances may differ).

GitLab gotchas we plan for:

• Keep GitHub in sync during the parallel run with GitLab's push mirroring. It is available on every GitLab tier, pushes to GitHub with a fine-grained token, and updates within five minutes of each push (one minute if you mirror protected branches only).
• include: and templates. Actions Importer merges included files into one job graph before converting. That gets a working workflow, but you lose the shared template. Rebuild shared steps as a reusable workflow or composite action in one repository.
• rules: and only/except convert to job-level if: conditions, partly. Read every converted condition; a wrong one means production deploys from a feature branch.
• Masked variables must be moved by hand. Use the move to retire the ones that are AWS keys (section 11).
• GitLab runners with tags become runs-on labels that point at nothing until you set up runners on the GitHub side.
• Ultimate security scanners (SAST, dependency and container scanning) don't convert, and their findings don't migrate. See section 15 before you move for that reason.

How do you migrate from Bitbucket to GitHub with history?

Full Git history moves with a mirror push from either Bitbucket Cloud or Data Center. Pull request history is the difference: GEI migrates it from Bitbucket Server and Data Center 5.14 and later, while GitHub's documented tools don't cover Bitbucket Cloud pull requests at all.

Bitbucket Data Center users aren't being pushed out. Atlassian's end-of-life plan for Data Center products (read-only from 28 March 2029) names Jira, Jira Service Management, Confluence and Crowd, and says Bitbucket and Bamboo Data Center "will not end of life". So moving off Data Center is a choice, not a deadline.

From Data Center, GEI brings history and pull requests with comments, reviews, file and line comments, required reviewers and attachments. It does not bring branch permissions, commit comments, repository settings, CI pipelines or repositories owned by individual users. LFS objects are pushed afterwards.

From Bitbucket Cloud, mirror the code and keep the Bitbucket workspace read-only as the pull request archive for as long as your auditors or your own curiosity need it. Community scripts exist that recreate pull requests through the API; we haven't vetted them, and recreated PRs lose their review state, so we rarely bother.

Bitbucket Pipelines gotchas (Actions Importer supports audit, forecast, dry-run and migrate for Bitbucket):

• size: 2x steps don't convert. Map them to a larger runner on purpose; they cost more per minute (see GitHub Actions pricing).
• oidc: true is unsupported, and BITBUCKET_STEP_OIDC_TOKEN has no mapping. If you already deploy to AWS with Bitbucket's OIDC, add GitHub as a second identity provider in IAM and give it its own roles.
• Build images from a private ECR repository are unsupported. Log in to ECR in a step first, using OIDC credentials.
• Secured repository, workspace and deployment variables, and SSH keys, are manual.
• Pipes don't appear in the importer's table of supported syntax. Plan for each Pipe to become an equivalent action or a few lines of shell, and check them one by one.

How do you migrate from Azure DevOps to GitHub?

Git repositories move with GEI's gh ado2gh extension or a mirror push; pipelines convert with Actions Importer; Azure Boards work items stay behind. GEI reads Azure DevOps Services (the cloud version) only; on Azure DevOps Server, use a mirror push or move to Services first. GEI generates a PowerShell script for a whole organisation, so on Mac or Linux install PowerShell first:

gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output migrate.ps1
./migrate.ps1

From Azure DevOps, GEI moves Git history, pull requests with their user history, work item links and attachments, and repository-level branch policies. That is the whole list: LFS objects, user-scoped and cross-repository branch policies, pipelines, work items (only their links on pull requests move), artifacts, test plans and dashboards stay behind. TFVC repositories have to be moved to Git first; that is its own project.

Pipeline gotchas:

• Actions Importer converts both build and release pipelines, but service connections, self-hosted agents, environments and pre-deployment approvals are manual.
• Pre- and post-deployment gates and post-deployment approvals are unsupported. Nested job templates produce invalid YAML and need fixing by hand.
• Actions Importer needs Azure DevOps Services or Azure DevOps Server 2019 or later.
• Approvals: Azure DevOps teams often rely on environment approvals. On GitHub, required reviewers on environments in private repositories need Enterprise (section 12). On Team you enforce the same control at the pull request instead.

UK data residency. Azure DevOps lets you host an organisation in the United Kingdom. GitHub's data residency (GHE.com, an Enterprise feature) is offered in the EU, Australia, the US and Japan; the UK isn't listed. If a customer contract names UK storage for source code, read it before you move.

How do you migrate Jenkins to GitHub Actions?

Run Actions Importer's audit against the Jenkins server, convert the declarative pipelines it can read, and rewrite scripted pipelines and shared libraries by hand. Jenkins hosts no code, so this is purely a CI move; your repositories may already be on GitHub.

What converts: freestyle jobs in part, and Jenkinsfile pipelines with docker and stage fully and agent, environment, steps, triggers and when partly. input, matrix, options and parameters don't. GitHub lists as always manual: scripted pipelines, secrets, self-hosted runners, unknown plugins and mandatory build tools.

Jenkins gotchas:

• The agent's IAM role. Jenkins on EC2 often deploys with the instance profile of the build machine: every job on it has the same AWS power, and nobody wrote that down. On Actions, each deploy job assumes a narrow role through OIDC instead.
• Shared libraries (@Library) are Groovy code. They become reusable workflows or composite actions, written by a person.
• State on the build server. Caches, tools installed by hand, a ~/.m2 or ~/.docker/config.json someone set up years ago. Hosted runners start clean every time; that is where the "mandatory build tools" line bites.
• Credentials. Nothing copies Jenkins' credential store into GitHub secrets. List every withCredentials block and decide, per credential, whether it can become OIDC.

You can also keep Jenkins and only move the repositories, if the pipelines are many and the Jenkins box is well looked after. We'd still move deploys to Actions with OIDC first, because that is where the security win is.

Do you have to migrate from CodeCommit to GitHub?

No. AWS closed CodeCommit to new customers on 25 July 2024, then reversed that: on 24 November 2025 it returned to full general availability, open to new sign-ups, with pricing and the 99.9% SLA unchanged. The same post put Git LFS support on the roadmap for Q1 2026; CodeCommit's documentation history has no entry for it as of 2 November 2026, so treat LFS on CodeCommit as unconfirmed.

Teams still move because pull requests, code review and CI live better next to each other. If you do, the move is a mirror push:

git clone --bare https://git-codecommit.eu-west-2.amazonaws.com/v1/repos/api api.git
cd api.git
git push --mirror https://github.com/acme/api.git

CodeCommit gotchas:

• Pull requests and comments don't move. There is no tool. Export what you need for audit evidence before you delete the repository; AWS notes deletion can't be undone.
• CodePipeline sources. A CodeCommit source action becomes a CodeStarSourceConnection action with the GitHub (via GitHub App) provider. Only a GitHub organisation owner can create the connection, and connections aren't available in a dozen Regions, including Hong Kong, Spain and Zurich. Check yours.
• IAM-based Git access goes away. CodeCommit access was IAM policy; on GitHub it is teams and repository roles. Re-create the access model deliberately.
• Approval rule templates and triggers (SNS, Lambda) become rulesets and webhooks or Actions workflows.

How do you migrate CircleCI to GitHub Actions?

Run Actions Importer against the CircleCI organisation, then finish contexts, orbs and runners by hand. If your code is already on GitHub, this is the smallest move on the page.

• Jobs, steps, matrices, parameters, triggers and cron triggers convert. Executors map to runs-on.
• Orbs are partly supported, mapped to actions. Unknown orbs, contexts and project-level environment variables are manual.
• Self-hosted runner executors, setup and version are unsupported.
• Caching between jobs of different workflows isn't converted. Expect the first week of builds to be slower until you tune actions/cache keys.
• The audit command works only with a CircleCI organisation account.

The usual reason to make this move is one bill and one place to look instead of two. Check the minutes maths in our GitHub Actions pricing guide before you assume Actions is cheaper for your build pattern.

How do you replace stored AWS keys with OIDC during the move?

Create GitHub's OIDC identity provider in each AWS account, give each deploy job its own IAM role that trusts only your repository and environment, and delete the old access keys once the rollback window closes. The migration is the cheapest moment to do it, because you are rewriting the deploy jobs anyway.

Not sure where all the stored keys are? Long-lived deploy keys are one of the things an AWS readiness review finds, alongside the rest of IAM.

1. Add the identity provider in IAM: provider URL https://token.actions.githubusercontent.com, audience sts.amazonaws.com. One per AWS account; it can sit next to a GitLab or Bitbucket provider during the parallel run.
2. One role per environment, with a trust policy pinned to the repository and the GitHub environment, not to the whole organisation:

   "Condition": {
     "StringEquals": {
       "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
       "token.actions.githubusercontent.com:sub": "repo:acme@111111/api@222222:environment:production"
     }
   }

   The catch for a migration: every repository you create on GitHub during the move is new, and repositories created after 15 July 2026 get an immutable subject claim with the numeric owner and repository IDs: repo:OWNER@OWNER-ID/REPO@REPO-ID:... instead of the older repo:acme/api:.... A trust policy written in the old, name-only form won't match, and the deploy fails at the role assumption. The IDs above are placeholders. GitHub's reference shows the new format for branches; check the exact sub your environment jobs send with a staging role before you rely on it.

3. Give the role only what the deploy does: push to one ECR repository, update one ECS service, pass one task role. Not AdministratorAccess "for now".
4. Switch the workflow to permissions: id-token: write and aws-actions/configure-aws-credentials with role-to-assume, as in section 10.
5. Deactivate, then delete, the old keys. Deactivate the IAM user's keys on cutover day plus one week; delete them a week after that. CloudTrail will show you if anything still used them.

If you were on GitLab with stored keys, note that GitLab CI also supports OIDC to AWS through id_tokens. The keys were a habit, not a platform limit, and the same fix would have worked there.

When should you not migrate to GitHub?

When the reason is fashion and the current setup works. A move costs one to three engineer-weeks and buys you nothing a customer sees. These are the cases where we'd tell you to stay:

• You're happy on GitLab. Merge requests, CI and runners all work, and nobody complains. GitLab does OIDC to AWS too. Spend the two weeks on the product.
• You use GitLab Ultimate's security features in earnest. SAST, dependency and container scanning, and vulnerability reports don't migrate. GitHub's equivalents are paid add-ons: Secret Protection at $19 and Code Security at $30 per active committer a month (checked 2 Nov 2026). Price that before you count the seat savings.
• You self-host for residency or isolation. GEI can't migrate GitLab into GitHub Enterprise Server, and GitHub's residency regions don't include the UK.
• You're mid-launch or mid-audit. Wait for a quiet month, or the end of the SOC 2 observation period.
• The only reason is CI cost. Price it first with GitHub Actions pricing; the fix is often in the workflow files, on whatever platform you're on.
• You're on CodeCommit because you were told it was shutting down. It isn't any more.

Going the other way? GitLab's own GitHub importer brings repository data, branches, issues, pull requests with reviews, comments, wiki pages, release notes, branch protection rules and LFS objects. CI isn't on its list: Actions workflows are rewritten as .gitlab-ci.yml by hand, the same job as this page in reverse.