Migrating a Repository from GitHub EDU to GitHub Enterprise


Migrating a Repository from GitHub EDU to GitHub Enterprise

Preconditions (performed once)

  1. Install GitHub CLI (gh) and the GEI extension (gh-gei).

    1. GitHub CLI: https://cli.github.com/
    2. GEI extension (gh-gei): https://github.com/github/gh-gei

  2. Confirm the following:

    1. You are migrating between GitHub products (GitHub EDU → GitHub Enterprise Cloud).
    2. You are the owner of an organization; or
    3. You have a migrator role in the organization(s) involved.
    4. Your destination environment supports public repositories (repo).

Note: GitHub docs note that public mode may not be available in some managed-user enterprise setups.

1) Create / confirm your PATs (classic) and export them

You will need to use two tokens:

Your gh auth status should show scopes such as admin:org, repo, and workflow, which is the right shape of scopes for gei usage. If you are missing workflow on either token, regenerate it with that scope.

export GH_SOURCE_PAT="ghp_sourcePersonalAccessToken"
export GH_TARGET_PAT="ghp_targetPersonalAccessToken"

2) Authenticate in gh using each token (and understand “active account”)

Important mental model

Log in with each token

echo "$GH_SOURCE_PAT" | gh auth login --with-token
echo "$GH_TARGET_PAT" | gh auth login --with-token

Then verify:

gh auth status

Both accounts should be listed, with one set to Active account: true.

3) Grant the Migrator role in the target org (utoronto-its)

If the person running migrations is not an organization owner, an organization owner must grant them the migrator role.

3.1 Make sure the active CLI identity is an org owner (or able to grant)

Granting the Migrator role is performed by an Organization owner, or someone permitted by organization policy. If you run the command as a non-owner, it will fail.

To receive permissions for a Migrator role, please submit a ticket to the AI Kitchen.

3.2 Grant migrator role to your user

gh gei grant-migrator-role \
  --github-org "utoronto-its" \
  --actor "[GitHub Username]" \
  --actor-type "USER"

This is the documented command shape: org + actor + type, where type is USER or TEAM.

Note: You may need to be granted the migrator role in both source and target organizations for migrations between GitHub products, depending on how your organization is set up. GitHub’s troubleshooting guidance explicitly calls out ensuring owner/migrator access on both sides.

4) Run the repo migration (public visibility)

Repos migrate as private by default. Use --target-repo-visibility public to keep it public.

gh gei migrate-repo \
  --github-source-org "EIS-ITS" \
  --source-repo "vss-cli" \
  --github-target-org "utoronto-its" \
  --target-repo "vss-cli" \
  --target-repo-visibility "public"

Typical output should be:

That is normal progress output for gei.

5) Post-migration verification checklist

  1. Open the target repo.
  2. Confirm the migrated content and settings.

Exact migrated artifacts can vary by repo content and settings, but this is the standard verification step for gei migrations.

6) Handle warnings and download the migration logs

Your run ended with:

GitHub documents log download using gh gei download-logs for migrations where the source is a GitHub product.

Download logs to a file (recommended)

gh gei download-logs \
  --github-target-org "utoronto-its" \
  --target-repo "vss-cli" \
  --migration-log-file "vss-cli-migration.log"

Then open vss-cli-migration.log and search for:

This will tell you exactly what the single warning was and whether you need to take any follow-up action.

7) Common issues

cannot fork