Move your repos. Keep your history.
PearlGit imports from any Git remote — GitHub, GitLab, Bitbucket, or plain Git over SSH/HTTPS. Most one-team migrations land in an afternoon. For larger ones, we run the import for you.
Source matrix.
What carries across by source. ✓ = migrated automatically; ◐ = migrated with caveats noted below; ✗ = manual.
| Source | Repos & history | Issues | Pull requests | Releases | Wikis | LFS |
|---|---|---|---|---|---|---|
| GitHub | ✓ | ✓ | ◐ | ✓ | ✓ | ✓ |
| GitLab | ✓ | ✓ | ◐ | ✓ | ✓ | ✓ |
| Bitbucket Cloud | ✓ | ✓ | ◐ | ✓ | ◐ | ✓ |
| Bitbucket Server | ✓ | ✓ | ◐ | ✓ | ◐ | ✓ |
| Plain Git (any remote) | ✓ | — | — | — | — | ✓ |
PR caveat (◐): comment threads, review history, and merge metadata carry across; some inline review-comment positions on long-since-rewritten diffs may not perfectly re-anchor. Wiki caveat for Bitbucket: their wiki format differs enough that some pages need manual fix-up after import.
The four-step path.
Get your source credentials ready
A read-token from the source host with access to the repos you want to migrate. PearlGit uses it once and discards it after the import completes.
Point PearlGit at the source
From New repository → Migrate, paste the source URL, paste the token, pick which artifacts to include (issues, PRs, releases, wiki, LFS). For org-wide migrations, use the admin import tool.
Validate
Spot-check a handful of repos: commit SHAs match, branches and tags line up, signed commits are still verified, LFS objects are reachable. PearlGits import job emits a manifest for diff against the source.
Cut over
Flip your CI configs and deploy webhooks to the new origin, update DNS or vanity URLs if you have them, and force-push your team to re-clone. The old host stays as a backup until you delete it.
What carries across automatically
- All commit SHAs (the hash is the same; no rewrite)
- All branches and tags, including annotated tags
- Signed commits remain verified (GPG signatures preserved)
- Git-LFS objects with their pointers intact
- Issues and labels (where the source supports them)
- Pull request diffs, comments, and merge state
- Releases including release notes and attached binaries
- Wiki pages (Markdown / reStructuredText / AsciiDoc)
Whats manual
- Webhook URLs — point them at the new origin
- CI configuration files (unless using Actions-compatible YAML)
- Deploy keys — regenerate on PearlGit and rotate at the deploy target
- Personal access tokens — re-issue on PearlGit
- External services (Slack notifications, status badges) — re-configure
- Team / permissions structure — admins recreate via PearlGits team UI
- Branch protection rules — explicit re-creation (each hosts model is slightly different)
For larger migrations.
If youre moving more than 100 repos, several teams worth of access controls, or compliance-significant data, well run the migration with you instead of leaving you to drive the import UI.
What that looks like:
- A migration call to map your source structure onto PearlGit (org → org, team → team, repo → repo).
- A dry-run import into a staging org so you can validate before cut-over.
- A cut-over window we coordinate around your release schedule, with the source host kept read-only for fall-back.
- A 30-day post-migration support window to catch the small things that always come up after.
This is a standard part of Team and Enterprise onboarding — no separate professional-services line item.
Migrating away later.
The honest fine print: if PearlGit ever isnt the right fit, you can leave cheaply. Because were plain Git underneath — no proprietary protocol, no opaque metadata format — your repos clone out to any other Git host without translation. The exit cost is roughly your teams coordination cost, not a re-platforming project.
This is the design choice that earns the trust we ask for. Wed rather have customers who could leave and dont, than customers who cant.
Ready to move?
Send us a rough description of your current setup (host, repo count, anything unusual) and well come back with a migration plan and a quote.