Move to GitHub without losing a commit
Repositories moved from Bitbucket, GitLab, Azure DevOps, SVN or your own Git server, with full history, branches and tags. Users, permissions, CI and integrations come across too, and the cutover is planned so nobody loses a day.
Sound familiar?
The red lines are where most teams start. The green lines are where you end up.
- Code is split across Bitbucket, GitLab and an old SVN server.
- Every repo lives in one GitHub organisation.
- A big-bang move feels too risky, so it keeps getting postponed.
- Repos move in planned waves, each checked before the next.
- Nobody is sure the history, tags and LFS files will survive.
- Commit counts, branches, tags and LFS objects are verified after every move.
- Bitbucket Pipelines or Jenkins jobs would all need rewriting by hand.
- Pipelines are rebuilt as reusable GitHub Actions workflows.
- After the move, people push to the old repo by mistake.
- Old repos are set to read-only, with a pointer to the new home.
What you get
Repositories with full history
Every branch, tag and commit moved across, including Git LFS files. SVN repositories are converted to Git with authors mapped, so history still says who did what.
Pull requests and metadata
Pull request and review history brought across where the source platform allows it (for example with GitHub Enterprise Importer for Bitbucket Data Center and Azure DevOps), otherwise archived alongside the repo.
Users, teams and permissions
People mapped to GitHub accounts, teams set up, repository access recreated, and organisation rulesets for branch and tag protection applied from day one.
CI pipelines rebuilt
Bitbucket Pipelines, GitLab CI, Azure Pipelines or Jenkins jobs rebuilt as GitHub Actions workflows, run side by side until the results match.
Integrations re-pointed
Jira links, webhooks, deploy keys, secrets and bots moved or recreated, so tickets and deployments keep working after the switch.
A planned cutover
A migration plan in waves, a short code freeze per wave, checks after each move, old repos set to read-only, and a rollback path if anything doesn’t match.
How it runs
Small moves take days, larger ones a few weeks. You get a fixed plan after the call, based on repo count and how much CI comes across.
- Step 1
Audit
Repos, sizes, LFS, users, pipelines and integrations listed.
- Step 2
Plan and pilot
Waves agreed, one pilot repo moved and checked with you.
- Step 3
Migrate in waves
Short freeze, move, verify, switch, one wave at a time.
- Step 4
CI and integrations
Pipelines rebuilt in Actions, Jira and webhooks re-pointed.
- Step 5
Handover
Old repos read-only, runbook, walkthrough, 30 days of support.
Price
Every codebase is different, so you get a fixed written quote after the call.
Migration to GitHub
From Bitbucket, GitLab, Azure DevOps, SVN or self-hosted Git.
After a free call · based on repos and pipelines
- Full history, branches, tags and LFS
- Users, teams, permissions and rulesets
- CI rebuilt as GitHub Actions workflows
- Jira, webhooks and secrets re-pointed
- Planned cutover with checks and rollback
Not included
- GitHub plan and seat costs, paid by you.
- Rewriting application code or build scripts beyond what the move needs.
Going further
- Pair it with a GitHub Actions platform so every migrated repo lands on shared, versioned workflows.
Migration questions
Will we lose any history?
Which platforms can you migrate from?
Do pull requests come across?
How long will developers be blocked?
Can you move us from Bitbucket Pipelines or Jenkins to GitHub Actions at the same time?
Thinking about moving to GitHub?
Book a free call and tell us where your code lives today. You’ll get a migration plan and a fixed quote.