Transferring Repositories Between GitHub Accounts

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production; see the section bibliography for the reference material consulted while preparing these pages.

This page shows how to change who owns a repository on GitHub — from one personal account to another, into or out of an organization, or between organizations — using GitHub’s built-in transfer, which moves the repository itself rather than copying it. The examples use the fictitious personal accounts jdoe-dev and asmith-dev, the fictitious organization acme-labs and the repository inventory-api. It targets Git 2.55.x, GitHub CLI (gh) 2.101.x, IntelliJ IDEA 2026.2, current stable VS Code and github.com as of October 2026. Moving a repository to a different host (for example from Bitbucket) is covered in Migrating Repositories Between Providers.

Concept

Transfer versus copy

A transfer changes the owner of the existing repository: it keeps its internal ID, and its issues, pull requests, wiki, stars, watchers and releases come along, because nothing is copied — the same repository simply appears under a new owner/repo path. A copy (git clone --mirror + git push --mirror into a new repository, as described in Migrating Repositories Between Providers) creates a second, unrelated repository with the same Git history but none of the GitHub data: no issues, pull requests, stars or settings.

Prefer a transfer whenever both accounts are on github.com and the transfer is allowed; fall back to a mirror copy when it is not (see When a transfer is not possible), or when you deliberately want the original to stay where it is.

The four directions

Direction Example Notes

Direction	Example	Notes
Personal → personal	`jdoe-dev/inventory-api` → `asmith-dev/inventory-api`	The new owner must accept the transfer by email; the old owner stays on as a collaborator.
Personal → organization	`jdoe-dev/inventory-api` → `acme-labs/inventory-api`	You need permission to create repositories in `acme-labs`; organization policies can block it.
Organization → personal	`acme-labs/inventory-api` → `asmith-dev/inventory-api`	Needs organization owner or repository admin rights; read-only collaborators are not carried over.
Organization → organization	`acme-labs/inventory-api` → `acme-platform/inventory-api`	Needs repository admin rights and permission to create repositories in the target organization; renaming as part of the transfer needs ownership of the target organization.

Personal → personal

jdoe-dev/inventory-api → asmith-dev/inventory-api

The new owner must accept the transfer by email; the old owner stays on as a collaborator.

Personal → organization

jdoe-dev/inventory-api → acme-labs/inventory-api

You need permission to create repositories in acme-labs; organization policies can block it.

Organization → personal

acme-labs/inventory-api → asmith-dev/inventory-api

Needs organization owner or repository admin rights; read-only collaborators are not carried over.

Organization → organization

acme-labs/inventory-api → acme-platform/inventory-api

Needs repository admin rights and permission to create repositories in the target organization; renaming as part of the transfer needs ownership of the target organization.

Derived from Transferring a repository.

Command line

GitHub CLI has no gh repo transfer command (only gh repo rename, gh repo archive and similar), so call the REST endpoint POST /repos/{owner}/{repo}/transfer through gh api:

# Personal account -> organization
gh api --method POST repos/jdoe-dev/inventory-api/transfer -f new_owner=acme-labs

# ... renaming it at the same time
gh api --method POST repos/jdoe-dev/inventory-api/transfer -f new_owner=acme-labs -f new_name=inventory-service

# ... and granting two acme-labs teams access (team IDs, not slugs)
gh api --method POST repos/jdoe-dev/inventory-api/transfer -f new_owner=acme-labs -F "team_ids[]=1234567" -F "team_ids[]=7654321"

# Personal account -> another personal account (asmith-dev must accept by email)
gh api --method POST repos/jdoe-dev/inventory-api/transfer -f new_owner=asmith-dev

The endpoint answers 202 Accepted: the transfer is queued and runs asynchronously, so the response does not mean it has finished, and a transfer to a personal account still waits for acceptance. new_owner is required; new_name is optional; team_ids (an array of integer team IDs, as returned by gh api orgs/acme-labs/teams) only applies to organization targets. -f sends a string field, -F a typed one (numbers stay numbers), and the [] suffix builds an array. Derived from REST API — Transfer a repository, gh api and gh repo.

When the transfer is done, update every clone:

git remote set-url origin https://github.com/acme-labs/inventory-api.git   # or git@github.com:acme-labs/inventory-api.git
git remote -v

On GitHub.com

Open the repository (for example jdoe-dev/inventory-api) and click Settings (if it is not visible, open the … dropdown and choose Settings).
Scroll to the Danger Zone section at the bottom of the settings page and click Transfer.
Under New owner, pick an organization you belong to (acme-labs) or type a username (asmith-dev); optionally change the repository name and, for an organization target, choose teams to grant access.
Read the warnings about features that may be lost, type the repository name to confirm, and click I understand, transfer this repository.

A transfer into an organization you can create repositories in completes immediately. A transfer to another personal account sends the new owner an email, and the repository only moves once they accept. Derived from Transferring a repository.

Requirements and what happens

Who can transfer. You need admin access to the repository. To move it into an organization you also need permission to create repositories there; for an organization-owned repository you need to be an owner of the organization or an admin of the repository.

Acceptance. A transfer to another personal account is only an invitation: the new owner gets an email and must accept it within one day, after which the invitation expires and you have to start again.

Blockers. A transfer fails if:

the target account already has a repository with the same name, or a fork in the same network;
the repository is a fork of a private upstream network;
the target account is not on github.com (repositories on github.com can only be transferred to owners on github.com), in which case you need a migration instead;
an organization policy forbids members from creating or transferring repositories.

What moves with the repository. Git history (including contributions), issues, pull requests, wiki, stars, watchers and releases; webhooks, secrets and deploy keys stay attached; Git LFS objects move in the background, which can take a while for large stores. Collaborators stay, and the previous owner is added as a collaborator.

What may need redoing. Read-only collaborators are dropped on an organization → personal transfer; in an organization the target’s default membership privileges apply, so check team access; issue assignments and issue types can change depending on the direction; packages may lose their link to the repository depending on the registry; GitHub App installations belong to an account, so check that the new owner has the apps the repository relies on; and a private repository moved to an account on GitHub Free loses features such as protected branches and GitHub Pages.

Redirects and their limits. Web links and Git operations (git clone, git fetch, git push) on the old jdoe-dev/inventory-api URL are redirected to the new location, but:

GitHub Pages project sites are not redirected — the site moves to the new owner’s Pages domain unless it uses a custom domain;
calls to a GitHub Action hosted in the repository (uses: jdoe-dev/inventory-api@v1) are not redirected and fail with "repository not found" until workflows are updated;
creating a new repository or fork with the old name under the old owner removes the redirect permanently;
if the repository published a GitHub Marketplace action, or saw more than 100 clones or more than 100 Actions uses in the week before, GitHub permanently retires the old owner/repo combination so it can never be reused.

Redirects are a safety net, not a destination: update remotes, CI configuration, submodule URLs, package metadata and documentation to the new path. Derived from Transferring a repository and Renaming a repository; both pages list exactly what each direction keeps, and are the reference if your case is not covered here.

When a transfer is not possible

When a blocker cannot be removed — the target is a different GitHub instance, the target already has a fork in the same network, or you need a copy while the original stays put — create an empty repository under the new owner and copy the history with git clone --mirror and git push --mirror, plus git lfs fetch --all / git lfs push --all if the repository uses Git LFS. That flow, including its pitfalls, is described step by step in Migrating Repositories Between Providers. Issues, pull requests, stars and settings do not come along with a mirror copy.

In IntelliJ IDEA

After the transfer, re-point the project’s remote: choose Git | Manage Remotes, edit origin, replace the URL with https://github.com/acme-labs/inventory-api.git, then run Git | Fetch. The steps are the same as in Migrating Repositories Between Providers — In IntelliJ IDEA.

In VS Code

Run Git: Remove Remote and Git: Add Remote from the Command Palette with the new URL, or git remote set-url origin https://github.com/acme-labs/inventory-api.git in the integrated terminal, as described in Migrating Repositories Between Providers — In VS Code.

Common mistakes / tips

Forgetting badges and links. README badges, documentation links and package.json / pom.xml repository URLs still name the old owner; they keep working through the redirect only until someone reuses the old name.
GitHub Pages URLs change. A project site at the old owner’s Pages domain moves with the owner; use a custom domain if the URL must stay stable.
Package coordinates. Packages published to GitHub Packages under the old owner (for example a container image under the old owner’s namespace) do not change their coordinates; consumers must be updated, and some registries drop the link to the repository.
Access through teams. In an organization, grant access through teams (team_ids or the team picker) rather than re-adding individual collaborators, and check that the organization’s base permissions are what you expect.
Plan differences. Branch protection, required reviewers, Pages for private repositories and some security features depend on the target account’s plan; review Settings after the transfer.
Retrying a personal transfer too late. The acceptance link expires after a day; if it lapses, start the transfer again.