SVN to Git Migration
- Atlassian Gold Solution Partner
- GitLab partner
- Delivering since 1999
- Public & private sector
Subversion (SVN) to Git is, honestly, one of the best-documented migrations in the industry. Git itself ships a bridge to Subversion, GitLab and GitHub both publish migration guidance, and Atlassian has run a public tutorial series on it for years. If your repository is a single project on a standard trunk/branches/tags layout, a competent engineer can do this migration with free tools in an afternoon.
That is not a sales pitch walked back — it is the honest starting point. We say it up front because a vendor who makes a well-solved problem sound hard is not being straight with you, and a repeat customer is worth more than one inflated engagement. Where we actually earn our fee is everything a straightforward SVN-to-Git tutorial does not cover: non-standard layouts, svn:externals, authors mapping across decades of commits, path-based authorization that Git has no equivalent for, and doing all of that across dozens of repositories instead of one.
The short answer: try the DIY path first if your repository is small and standard. git svn is built into Git, GitLab and Atlassian both document the process, and SubGit can do a one-time import with no license required at all. Call us when your layout is not standard, when you have thirty repositories and one weekend, when authorship history needs to be right rather than approximate, or when the migration is one piece of a larger platform move.
Why teams are moving off SVN
- Local commits and offline work. Subversion requires a network round trip to the central server for history operations that Git does entirely locally.
- Branching that is actually cheap. Git branches are lightweight pointers; SVN branches are directory copies, and merge tracking is comparatively weak.
- Ecosystem and hiring. Code review tools, CI/CD systems and most new hires assume Git. SVN experience is a shrinking skill in the job market.
- Consolidation onto a single platform. Teams already using GitLab, GitHub or Azure DevOps for planning and pipelines often want source control on the same platform rather than bridged to it.
The well-trodden path: tools that already solve this
| Tool | What it is |
|---|---|
| git svn | Bundled with Git. GitLab’s own migration documentation names it as the recommended option for small, simple repositories with a standard layout. |
| svn2git / svn-all-fast-export | Community conversion scripts (the KDE project’s svn-all-fast-export is the best known) built for large, complex SVN histories that git svn handles slowly or poorly. |
| SubGit | A commercial tool that can mirror SVN and Git live during transition. A one-time, one-way import needs no license at all; ongoing bidirectional mirroring or support needs a paid license, with free options for open source and academic projects. |
| GitLab’s own guidance | GitLab does not import SVN automatically. Its documentation points to git svn for small repositories and reposurgeon for large, complex ones, and offers GitLab Professional Services as a paid alternative to doing it yourself. |
| Atlassian’s SVN-to-Git tutorial series | A multi-part, free tutorial (prepare, convert, share) built around git svn plus Atlassian’s own svn-migration-scripts helper jar, aimed at teams moving onto Bitbucket or any Git host. |
Any of these will get a clean, standard-layout repository converted with history intact. If that describes your situation, start there — we would rather you succeed for free than pay us to run a command we would run the same way.
Where the well-documented path stops helping
The tutorials above generally assume one repository, a standard trunk/branches/tags layout, and authorship you do not care about mapping precisely. Real SVN estates rarely match all three, and this is where an outside team earns its keep:
Non-standard layouts
Repositories that never followed trunk/branches/tags need a custom path map before any converter can infer branch and tag history correctly.
Authors mapping
SVN commits are usually just a username. A correct Git author (name and email) mapping table, built and verified against years of commit history, is tedious and easy to get subtly wrong.
svn:externals
SVN’s mechanism for pulling in other repositories has no direct Git equivalent. Each external becomes a decision: Git submodule, Git subtree, or a package-manager dependency instead.
svn:ignore and svn:keywords
Ignore patterns convert to .gitignore, but keyword expansion ($Id$ and similar) has no native Git equivalent and needs a deliberate replacement or a decision to drop it.
Empty directories
Git does not track empty directories at all. Anything your build tooling depends on existing needs a .gitkeep-style placeholder or a build-script fix.
Binary files
SVN stores every binary revision as a full copy already; Git does too unless you route large or frequently-changing binaries into Git LFS as part of the conversion, not afterward.
Path-based authorization
SVN’s authz file grants access by repository path. Git has no path-level permission model on any major host, so this becomes a repository-splitting decision, not a settings change.
Monorepo splitting (or merging)
One SVN repository holding many projects has to be split, kept whole, or restructured, and that decision should be driven by permissions, size and release cadence, not by how the repository happens to be laid out today.
Add large history (tens of thousands of revisions), CI and hook rewiring, and training a team that has only ever known SVN’s centralized model, and “run git svn clone” stops being the hard part of the project.
SVN concepts, mapped to Git concepts
| In Subversion | In Git |
|---|---|
| Single central repository, trunk/branches/tags | Distributed repositories; branches and tags are native, lightweight objects |
| Revision number (global, incrementing) | Commit SHA (per-repository, content-addressed); revision numbers are not preserved as identity |
| Working copy | Local clone with full history, not just the checked-out revision |
svn:externals | Git submodule, git subtree, or a package/dependency manager reference |
svn:ignore | .gitignore |
svn:keywords | No native equivalent; requires a filter/attribute-based workaround or removal |
authz path-based permissions | Repository- and group-level roles; no native per-path equivalent |
| Directory copy as a branch | Lightweight branch pointer |
How we run an SVN to Git migration
Assessment
We inventory your repositories, layout, externals, authz rules and binary footprint, and tell you honestly whether this is a DIY job or one that benefits from help.
Mapping
Authors, paths, externals and permission boundaries mapped to a Git structure your teams sign off on before conversion runs.
Pilot
One repository converted end to end to validate the mapping and give a real estimate for the rest, rather than a guess based on repository count alone.
Full migration & reconciliation
Every repository converted with history, tags and authorship intact, with counts and spot checks before SVN is retired.
Parallel-run
SubGit-style mirroring or a read-only SVN instance kept available while teams transition, so there is a rollback path.
Training & licensing
Hands-on Git training for teams moving off a centralized workflow for the first time, and licensing help on whichever Git host you land on.
Who we help
- Teams with dozens of SVN repositories who need consistent authors mapping and a repository-splitting decision applied uniformly, not repository by repository.
- Organizations with
svn:externalsor path-basedauthzwhere a straightforward conversion silently drops something that mattered. - Regulated and public-sector organizations that need the resulting Git host self-managed or air-gapped to match a compliance boundary SVN already satisfied.
- Teams moving SVN and their planning tools together, for example onto GitLab — see our Jira and Confluence to GitLab migration page if that is part of the same project.
Related migrations: Perforce to Git, ClearCase to Git, Bitbucket to GitLab. Or see all our tool migration services.
Frequently asked questions
Can we just do this ourselves?
Often, yes. If you have one repository on a standard trunk/branches/tags layout and do not need precise authorship mapping, git svn plus GitLab’s or Atlassian’s published guides will get you a working conversion for free. Call us when your layout is non-standard, you have many repositories, or authorship and permissions have to be right rather than approximate.
What is SubGit, and do we need to pay for it?
SubGit is a commercial tool for mirroring SVN and Git during a transition. A one-time, one-way import needs no license at all. A paid license is needed for ongoing bidirectional sync past a trial period, or for support; free and discounted licenses exist for open source and academic projects.
What happens to svn:externals?
They have no direct Git equivalent and become a per-case decision: a Git submodule, a git subtree, or a dependency pulled through a package manager instead. This is one of the most common things a rushed conversion gets wrong, because the tooling will not flag it for you.
Does GitLab or GitHub import SVN automatically?
No. GitLab’s own documentation says it cannot automatically migrate Subversion repositories, and points to git svn for small repositories or reposurgeon for large, complex ones, with GitLab Professional Services offered as a paid alternative. GitHub has no first-party SVN importer either; the conversion runs through the same external tools regardless of destination.
What about SVN revision numbers builds might depend on?
Revision numbers do not survive as Git commit identity. If anything in your build or release process pins to an SVN revision number, plan its replacement — a tag, a commit SHA, or a version manifest — before cutover rather than after a build breaks.
Can we run SVN and Git side by side during the transition?
Yes. SubGit’s mirroring mode is built for exactly this, keeping both systems in sync while teams move over. A read-only SVN instance kept available after cutover is a simpler, cheaper fallback if bidirectional sync is not needed.
Tooling behavior and licensing verified 26 September 2026 against Git’s own git-svn documentation, GitLab’s Subversion migration documentation, subgit.com, and Atlassian’s SVN-to-Git tutorial series. Terms and license conditions change; confirm current details before you budget. ReleaseTEAM is an Atlassian Gold Solution Partner and a GitLab partner.
Straightforward migration, or a mapping puzzle? Let’s find out together.
Tell us what your SVN estate actually looks like — layout, externals, authz, history size — and we will tell you honestly whether you need us at all.
Speak With An Expert