Introduction

Moving an existing Git repository to a different remote server is a routine migration task, but it is easy to do incompletely. Branches, tags, large-file objects, and server-side settings all need attention. A safe migration keeps the old remote available while you transfer, verify, and only then cut over daily work.

Inspect the Repository Before You Move It

Start by recording what the local repository currently knows about its remotes and refs. That gives you a baseline for verification later.

1git remote -v
2git branch -vv
3git tag --list | wc -l
4git status --short

If the working tree is dirty, decide whether to commit, stash, or discard that work before migration. The remote transfer itself does not depend on a clean working tree, but validation is much simpler when local state is not changing underneath you.

It is also reasonable to create a local safety tag before the migration:

git tag migration-snapshot-2026-03-07
git show --quiet migration-snapshot-2026-03-07

That is not required by Git, but it gives you an obvious marker for the repository state at cutover time.

Add the New Remote Without Replacing the Old One

Do not overwrite origin immediately. Add the new destination as a second remote first.

git remote add new-origin git@new-host:team/project.git
git remote -v
git ls-remote new-origin

Keeping both remotes during migration makes rollback and comparison easier. If authentication fails at this stage, fix keys, tokens, or SSH configuration before pushing anything.

This is also the moment to confirm whether the new host expects the repository to exist already or whether it can be created automatically by push.

Push Branches and Tags Explicitly

For most migrations, you want all local branches and all tags.

git push new-origin --all
git push new-origin --tags

That is enough for many ordinary repositories. If the repo uses extra ref namespaces, notes, or other nonstandard references, consider a mirror workflow instead.

git clone --mirror git@old-host:team/project.git project.mirror.git
cd project.mirror.git
git push --mirror git@new-host:team/project.git

Mirror pushes are powerful because they copy the full ref space. They are also dangerous because they can overwrite refs on the destination. Use them only when you understand the target state.

Do Not Forget Git LFS and Server Settings

A ref migration is not always the full repository migration. If the project uses Git LFS, large objects need their own push and validation path. Likewise, branch protections, deployment keys, webhooks, CI integrations, and repository permissions do not move just because commit history does.

That is why a repository migration plan usually has two layers:

• Git data transfer
• hosting-platform configuration transfer

The first layer is visible in git log. The second layer is where many real migrations fail.

Verify Before You Cut Over

Before switching developers to the new remote, verify parity.

Useful checks include:

1git for-each-ref refs/heads --format='%(refname:short)' | wc -l
2git ls-remote --heads new-origin | wc -l
3git ls-remote --tags new-origin | wc -l
4git rev-parse main
5git ls-remote --heads new-origin main

Also verify a few critical branches by hash, not just by count. Branch count parity can still hide a missing or stale branch if the wrong set of branches got pushed.

For platform settings, manually confirm:

• default branch
• branch protection rules
• required checks
• CI or deployment hooks
• repository visibility and team access

Cut Over Daily Usage

Once verification is complete, rename the remotes so the new host becomes the default origin.

git remote rename origin old-origin
git remote rename new-origin origin
git remote -v

Then push a temporary smoke-test branch to confirm ordinary developer workflows still work:

git switch -c migration/smoke-test
git push -u origin migration/smoke-test

Delete that branch after the test succeeds.

Common Pitfalls

The most common mistake is replacing origin too early and losing an easy rollback path. Another is pushing only the default branch and forgetting tags or maintenance branches. Teams also often validate Git history but forget branch protection, CI hooks, or Git LFS objects, which leads to a repository that looks correct and still fails normal usage.

Summary

• Keep the old and new remotes side by side during migration.
• Push branches and tags explicitly, or use mirror mode when full ref parity is required.
• Treat Git data and hosting-platform settings as separate migration tasks.
• Verify branch, tag, and commit parity before cutover.
• Rename remotes only after end-to-end validation succeeds.