Repository migration and backup

Repository hosting with complete import, export, mirroring, and backup

The key distinction is that Git mirroring is not the same as backing up a repository's full project history and metadata. A standard Git mirror preserves commits, branches, and tags, but generally does not preserve issues, code reviews, review comments, pull or merge requests, or release attachments.

For a service to meet your requirements, evaluate three separate capabilities:

• Import/export: Can you migrate project data to another instance or provider and recover it later?
• Continuous mirroring: Can changes be replicated to an independent hosting service?
• Restorable backups: Can you recover both the Git repository and its associated collaboration data, including reviews and releases?

Based on the official documentation and provider-specific capabilities, these are the main options worth evaluating.

Best candidates

• 

1. Forgejo — best for self-hosted control and full-instance recovery

(Strong backup path)

Forgejo supports repository migration and documents full-instance backup and restoration, including the database, Git repositories, file storage, and configuration secrets. This gives you a path to recover collaboration metadata rather than relying only on a Git clone. Its newest migration capabilities also include importing pull requests, reviews, comments, threads, and replies from supported sources.forgejo.org+1

Caveat: This is strongest when you control both the source and destination Forgejo instances. Cross-provider import and continuous synchronization still need to be verified feature by feature.

Links: Backup and restore documentation ·Forgejo

---

• 

2. GitLab — strong project migration tooling

GitLab project exports can preserve repositories, issues, merge requests, and comments. GitLab also offers repository push and pull mirroring, with pull mirroring restricted to Premium and Ultimate tiers.docs.gitlab.com+2

Important limitation: GitLab explicitly warns against using project export files as backups. Exports omit some data, and only the latest merge-request diff version is preserved. Some user attribution can also change during migration. Therefore, exports alone do not satisfy a strict zero-loss requirement.

Links: Project import/export ·Repository mirroring

---

• 

3. Gitea — lightweight self-hosted alternative

Gitea provides a dump command for packaging an installation for backup and documents how to restore the installation. Backing up the database and repository files together is important because issues and other user interactions are stored separately from Git history.docs.gitea.com+1

Caveat: A full installation backup is not the same as a portable, cross-provider export. Validate migration of review threads, release assets, attachments, and author identities for your specific source and destination.

Links: Backup and restore ·Gitea

---

• 

4. GitHub — broad ecosystem, but requires a separate metadata backup strategy

GitHub documents repository backups using git clone --mirror, which preserves Git history and references. It also supports third-party and API-based backup approaches for additional data.docs.github.com

Caveat: A mirror clone does not by itself export issues, pull-request review discussions, release metadata, or uploaded assets. A separate API-based backup and tested restoration workflow are needed.

Link:GitHub repository backup guide

Which services actually preserve all the data?

Here is the practical comparison for a migration or disaster-recovery plan.

These are capability summaries, not guarantees that every cross-provider migration preserves every field. See the respective Forgejo, GitLab, Gitea, and GitHub documentation.

Recommended architecture for zero-loss recovery

Rather than depending on one provider's import/export feature, use three independent layers:

Layer 1 — Live repository replica

Mirror Git branches, tags, and commit history to a second independent host. Include Git LFS objects and wiki repositories where applicable.

---

Layer 2 — Complete metadata backup

Export issues, pull/merge requests, review approvals, inline comments, discussion threads, labels, milestones, releases, release assets, attachments, and relevant identities using provider APIs or native database backups.

---

Layer 3 — Independent, versioned backup

Store encrypted, versioned backups outside the hosting provider's account and infrastructure. Periodically restore into a clean instance and verify metadata, permissions, assets, and review history.

My recommendation: Start with Forgejo if you want control over your hosting and recovery process. Consider GitLab if project migration and integrated mirroring are priorities. In either case, pair the host with a metadata-aware backup tool or custom API exporter and test restores before trusting it.

One final distinction: a backup can preserve data perfectly while still not being importable into another vendor with all relationships intact. If your requirement is genuinely no loss of issues, reviews, release metadata, and attachments when switching providers, you must validate both the export format and the destination's import capabilities.

The short answer is no mainstream native Git repository hosting service (like GitHub, GitLab, or Bitbucket ) provides continuous, automated real-time bidirectional mirroring for non-code metadata (issues, pull request reviews, and release metadata) out of the box. Standard Git mirroring (--mirror ) strictly synchronizes the bare Git database—commits, branches, and tags.

However, complete paths do exist depending on whether you mean one-time/periodic migration, specialized self-hosted platforms , or third-party enterprise backup solutions.

1. Self-Hosted Platforms (Gitea / Forgejo)

• What they do: Gitea and Forgejo support comprehensive repository migration tools that natively pull in issues, pull requests (converted to native representations with discussion history), labels, milestones, releases, and wikis upon initial import.gitea-mirror.raylabs.io
• The Catch on Mirroring: While Gitea has discussed extending pull-mirrors to continuously track issue/PR updates, native continuous mirroring on standard configurations still focuses primarily on Git refs (code, tags) rather than living, updating issue/PR streams. Keeping metadata fully synced continuously requires re-running migration hooks or using external automation scripts.github.com

2. Specialized Third-Party Enterprise Backups (Full-Fidelity Backup & Restore)

If your goal is a true backup path that captures everything without losing metadata (issues, PR reviews, comments, project boards, and release assets) and allows a non-destructive restore, you must look to dedicated SaaS backup providers:avepoint.com

• AvePoint GitHub Backup: Offers full-fidelity backup of repositories alongside all non-code metadata (issues, pull requests, releases, project boards, wikis, and labels) with automated scheduling and targeted restores.avepoint.com
• Other DevOps Backup Tools: Solutions like Rewind or GitProtect specialize in API-driven periodic snapshots of GitHub/GitLab organizations to preserve issues, pull requests, and metadata outside of standard Git bundles.

3. Native Import/Export Utilities (Point-in-Time Archives)

• GitHub Migration APIs: GitHub allows you to generate organization or repository migration archives via their REST API, which packages up repositories, issues, and pull requests. However, these are strictly point-in-time export paths, lack continuous mirroring, and have limitations regarding LFS objects or direct external restores.
• GitLab Import/Export: GitLab has robust project JSON export/import functions that bundle code, merge requests, issues, comments, and labels into a single archive file, though it acts as a manual migration path rather than a live mirror.docs.github.com

If you'd like, let me know:

• Are you looking for a self-hosted solution (like Gitea) or a cloud-to-cloud backup/mirroring tool?
• What is your primary source host (e.g., GitHub, GitLab)?

I can provide the specific CLI commands, API workflows, or configuration setups tailored to your environment.

For your requirements, I’d start with GitLab, especially if you want a platform that supports repository mirroring, structured project migrations, and backups while retaining collaboration history.

The important distinction is that mirroring Git repositories is not the same as backing up an entire development project. Branches and commits are relatively easy to mirror; issues, code-review discussions, approvals, releases, attachments, and other metadata require additional migration support.

Best options to evaluate

• 

1. GitLab — best overall fit

(Top recommendation)

GitLab combines project import/export, repository mirroring, and full-instance backup and restore for self-managed installations. Project exports support issues, merge requests, comments, reviewers, and releases.docs.gitlab.com+5

• Mirroring: Push and pull mirroring; bidirectional mirroring is also available.docs.gitlab.com
• Backups: Instance-level backups cover repositories, database records, and collaboration data.docs.gitlab.com+3
• Caveat: Project exports are not complete backups. Some data is excluded, and only the latest merge-request diff version is preserved in file-based migrations.docs.gitlab.com+4

Official migration documentation

---

• 

2. GitHub Enterprise Cloud — best for enterprise migrations to GitHub

GitHub Enterprise Importer supports migration from GitLab, Bitbucket Data Center, Azure DevOps, and other supported sources, preserving substantial collaboration history, including issues and pull requests.docs.github.com+3

• Reviews: Migration tooling preserves much review history, but certain comments or review threads can fail to migrate.github.com
• Caveat: It is primarily a migration into GitHub Enterprise Cloud, not a universal round-trip import/export solution. Metadata size limits and other exceptions apply.docs.github.com

Official migration documentation

---

• 

3. Forgejo — best for self-hosting and control

Forgejo offers repository mirroring and self-managed backup procedures, making it appealing if you want control over your infrastructure and data.forgejo.codeberg.page+4

• Mirroring: Branches, tags, and commits.
• Backups: You manage database and repository storage backups.
• Caveat: Verify the source-to-destination migration path carefully if preserving review discussions, approvals, and release assets is mandatory. Repository mirroring alone will not preserve all this metadata.

Official backup documentation

How they compare against your requirements

This is a capability comparison, not a guarantee that every item survives every migration path. GitLab's backup and export mechanisms are distinct, and GitHub's importer has its own limitations.docs.gitlab.com+3

My recommendation

Choose GitLab Self-Managed if you want a unified platform for hosting, migration, mirroring, and recoverable backups. Its instance-level backup and restore capability is particularly useful when your goal is to preserve the complete working environment rather than just the Git repositories.

Before committing, run a pilot migration and verify issue comments, review threads, approval history, release descriptions and assets, tags, and user attribution. Maintain a separate backup and test restoration rather than relying on exports alone.

One question that would change my recommendation: Which platform are you migrating from?

Current code hosting platform

GitHub

GitLab

Bitbucket

Azure DevOps

Other or multiple platforms

---

Preferred destination

GitLab

GitHub Enterprise

Forgejo or Gitea

Open to either

---

Hosting preference

Cloud-hosted

Self-hosted

Either

[Find the best migration path]