Moving Your Repositories to a New Git Server Without Losing Anything

Moving hosts feels risky because the repo is the crown jewels. The good news: Git is a distributed system, and every clone already contains the complete history. Migrating is mostly a matter of pushing that history somewhere new - plus remembering the things that are not in the repo.

The mirror push#

The recipe for a lossless move is three commands:

git clone --mirror git@old-host:your-org/your-app.git
cd your-app.git
git push --mirror git@new-host:your-org/your-app.git

--mirror on the clone fetches every branch, every tag, every note - not just the default branch checkout. --mirror on the push replicates all of it, exactly, onto the new server. When the push finishes, the new repo is a bit-for-bit copy of the old one’s refs. History, tags, branches: done.

What does not travel#

The repository is only part of what makes a project work. Plan separately for:

• Pull requests and issues. These live in the host’s database, not in Git. GitHub’s API can export them; some teams archive them to a document and start fresh, some use migration tooling. Decide consciously - do not discover the gap after the cutover.
• CI secrets and variables. Re-enter them on the new side. This is also a natural moment to apply the scoping rules from deploy keys and machine users instead of copying an old personal key.
• Webhooks and integrations. Deploy hooks, Slack notifications, status checks - make a list before you start, and tick each one off on the new server.
• Branch protection rules. Recreate them; branch protection rules that stick is the checklist.

The order that avoids pain#

1. Set up the new server and recreate protections while the old one still serves everyone.
2. Mirror-push every repo, and spot-check: clone from the new host, run the test suite, compare git log on a few branches.
3. Move one non-critical repo first as a dress rehearsal for the team’s workflow changes.
4. Announce a short freeze on the old host, do a final mirror push to catch the last commits, then update everyone’s remotes: git remote set-url origin git@new-host:your-org/your-app.git.
5. Keep the old host read-only for a month. Deleting it on day one is how you find out what you forgot.

If you are moving to self-hosted, the prep work is the same - plus the operational habits in backing up your Git server from day one, because the safety net is now yours to run.

The history is the easy part; Git was built for this. The checklist above is the difference between a quiet migration and a week of “did anyone move the webhook?”