Your GitHub organization owner clones the repositories you choose, then creates GitHub's migration archive for the same ones. A clone is a copy of the repository itself. The archive, a .tar.gz that must be under 20 GB and that GitHub deletes after seven days, holds issues, pull requests, reviews and comments. You, or whoever runs your systems, run the removal tool on your own computer and review flagged items there. You upload only the cleaned package. We never connect to GitHub.
Who runs it
Who can run it: An organization owner with owner access to each chosen repository. The archive needs a classic access token with the repo and admin:org scopes, which the owner creates and keeps. GitHub says the export can take several minutes, depending on the number of repositories being exported.
GitHub's pages describe this route for an organization only, and GitHub says the Migrations API is currently in a preview period, so the endpoints and parameters may change.
Before you start, read How to export your GitLab projects and How to export your Google Workspace data.
Choose the repositories first
Pick the repositories with your firm's own work: internal tools, infrastructure, your products. Leave out any that hold a client's code, other people's licensed code or personal projects. We go through the list with you on the call.
Clone the code
Copy each chosen repository's clone URL and run git clone https://github.com/OWNER/REPOSITORY.git. GitHub says git clone grabs a complete copy of a repository. Compress each folder and keep it on your computer for the removal tool.
Export issues and pull requests
Your owner starts GitHub's migration archive with one request to GitHub's own API, using their own token. We send the exact command for your repository list.
- Create a classic token with
repoandadmin:org. - Start the migration for the chosen repositories. GitHub says to set
lock_repositoriesto true and calls that highly recommended, and it strongly recommends locking a repository that is in use. The default is false. Locking prevents all write access to the repository until it is unlocked, and GitHub has an Unlock an organization repository endpoint. For a repository nobody is writing to, your owner can leave it off. - When the status reads
exported, download the archive. - Download it within seven days, then revoke the token.
GitHub says the archive holds wikis, issues with comments, pull requests, reviews, commit comments, releases, milestones and file attachments on issues and pull requests. It also carries active webhooks, repository deploy keys and protected branch settings. GitHub says file-level comments are not migrated, Git LFS assets cannot be migrated, and fork relationships do not persist.
If the status reads failed, GitHub says the migration failed. Check that the owner holds owner rights and the token has both scopes, then start again with fewer repositories. If the archive would be too large, GitHub suggests excluding attachments, which can be large. After seven days the archive is gone, so start a new migration.
Review the cleaned package on your computer before you upload
Your export stays on your computer. Check that it is complete, then run the removal tool and review the cleaned package there before you upload anything.
- List the repositories you chose and compare them with the repositories in the archive. Write down any that are missing. GitHub documents a List repositories in an organization migration endpoint that lists all the repositories for a migration.
- For each clone, confirm that its latest commit is the same as the latest commit GitHub shows for the default branch.
- Write down what GitHub says is not migrated: file-level comments, Git LFS assets and fork relationships. If a repository uses Git LFS, tell us.
- Note the day you made the archive and whether you locked the repositories.
- Open the archive and confirm it unpacks. GitHub deletes the remotely hosted migration archive after seven days; that does not expire your downloaded local copy. Start a new migration only if the remote archive expired before you downloaded it.
What the removal tool strips, and what stays out
The removal tool strips names, usernames, emails and avatars of staff and contributors and replaces them with consistent labels. It strips passwords, keys, tokens and connection strings in code, commits and comments, and client names in code comments, issues and branch names.
The archive carries active webhooks, repository deploy keys and protected branch settings, which stay out because a deploy key or a webhook address can hold a credential. Client-owned code and client production data stay out unless the client agrees in writing. So does code under licenses that don't allow this use. You review the tool's flagged items on your own computer and a cleaned sample before any buyer sees it (how personal data is removed). Buyers like HUD's DataVendor ask for codebases, and the issue-to-pull-request trail shows why the code changed (why we ask for an export).