Perforce to Git Migration
- Atlassian Gold Solution Partner
- GitLab partner
- Delivering since 1999
- Perforce sales & support
“Perforce to Git” almost never means one destination. Perforce, now branded P4 by Perforce Software (it was Helix Core until the company folded that name back into the original P4 brand in 2025), is a centralized version control system built for huge binary-heavy depots. Git itself is just a protocol and a data model — the decision that actually shapes your migration is which Git host you land on.
GitLab, GitHub, Bitbucket and Azure Repos all speak Git, and all can receive a Perforce conversion. They differ in ways that matter for a Perforce shop specifically: how they handle large binaries, whether file locking exists at all, how big a repository or push is allowed to be, and whether you can run the platform yourself or only as hosted SaaS. We sell and support Perforce (see Perforce sales, support and consulting) and are a GitLab partner, so we have no reason to steer you toward a destination that does not fit your depot.
The short answer: pick the Git host before you pick the conversion tool. If your depot is code-only or lightly binary, any of the four hosts will work and the choice comes down to CI/CD, self-managed vs. SaaS, and where your teams already live. If you carry large binaries, exclusive locks, or a hard permissions boundary, the host you choose determines whether Git LFS locking, storage limits and self-managed options can actually cover what Perforce’s +l file type and p4 protect tables do today. We have a deep, GitLab-specific breakdown of what does and does not survive at Perforce to GitLab migration: what moves, what breaks, and when not to — this page is the head-to-head across all four destinations.
Why teams move off Perforce
- Ecosystem gravity. CI/CD, code review and IDE integrations are mostly Git-first; Perforce works with them, but as an integration, not a native citizen.
- Developer familiarity. New hires increasingly know Git and not Perforce — a recurring onboarding cost, not a one-time one.
- Distributed workflow. Local commits, branching and offline work fit teams not all on one low-latency network to a central server.
- Toolchain consolidation. Standardizing planning and CI/CD on GitLab, GitHub or Azure DevOps while source stays in Perforce leaves a permanent integration seam.
None of these are Perforce weaknesses so much as Git strengths for a particular kind of team. If your depot is binary-heavy, lock-dependent or permission-fenced, the calculus can run the other way. Our Perforce to GitLab page spells out those cases — large binaries, media pipelines, exclusive locking, terabyte-scale depots and per-directory permissions are all legitimate reasons to stay, and we will say so before we take the work.
Choosing the Git host: what actually differs
Every one of these platforms accepts a Perforce-to-Git conversion. What changes is how much of Perforce’s binary and locking model survives the trip, and how the platform is priced and hosted. The figures below are the vendor’s own published numbers; verify them again before you commit, because they move.
| Git host | Repo / push limits | LFS & file locking | Self-managed option |
|---|---|---|---|
| GitLab | GitLab.com Free: 10 GiB repo incl. LFS; Premium/Ultimate: 500 GiB. Push capped at 5 GiB per request (Cloudflare) | Git LFS on every tier; LFS exclusive locks (.gitattributes) on every tier; UI-enforced default-branch file locks on Premium/Ultimate, default branch only | Yes — GitLab Self-Managed, including air-gapped |
| GitHub | Recommends repos stay under 1 GB, “strongly” under 5 GB; command-line push blocks files over 100 MB | Git LFS available, size caps vary by plan; native git lfs lock file locking supported | Yes — GitHub Enterprise Server |
| Bitbucket | Cloud: 4 GB hard repo limit, 2 GB recommended; a push file-size limit applies separately | Git LFS on Cloud with no published per-file cap (5 GB media-upload ceiling); LFS file locking is Data Center/Server only (6.3+) — not supported on Bitbucket Cloud | Yes — Bitbucket Data Center |
| Azure Repos | Hard ceiling 250 GB, Microsoft recommends under 10 GB; pushes capped at 5 GB; standard blobs recommended under 100 MB | Git LFS supported; locking follows the standard Git LFS locking API | Azure DevOps Server (on-premises) |
None of these come close to Perforce’s own ceilings. Perforce depots routinely run into the terabytes with no equivalent size wall, and the +l file type is a server-enforced exclusive lock that fails the checkout up front. Git LFS locking, where it exists at all, is advisory: it fails at push time, after the work is already done, and (outside GitLab Premium/Ultimate default-branch locks) is not enforced by the server at all. If your depot leans on either property heavily, read the host row twice before you commit to a cutover date.
Perforce concepts, mapped to Git concepts
| In Perforce (P4) | In Git |
|---|---|
| Depot | Repository (often one Git repo per depot, or split by permission/size boundary) |
| Stream / branch | Branch, inferred by conversion tooling from depot structure |
| Workspace / client spec | Working directory + local clone; every developer rebuilds this after cutover |
| Changelist | Commit (numbered identity is not preserved as-is; usually kept as text in the commit message) |
| Label | Tag (partial fidelity depending on the converter) |
| Shelve | No direct equivalent; closest is an unpushed local commit or a draft merge/pull request |
| Trigger | Server-side hook, or a CI/CD pipeline job on the host |
p4 protect table | Repository- and group-level roles and permissions; no native per-path equivalent on any of the four hosts above |
What the conversion tooling does, and where it stops
None of the four hosts ship a first-party Perforce importer. Conversion runs through the same handful of open source tools regardless of destination:
- git-p4, bundled with Git itself, is the default starting point for most conversions and the one every vendor’s documentation points to.
- p4-fusion, an open source bulk converter, trades setup complexity for speed on large histories, and preserves Perforce integrations as merge commits with better fidelity than git-p4.
- Perforce’s own P4 Git Connector mirrors Git content into a Perforce graph depot and speaks Git to any of the four hosts above, which is a legitimate hybrid path if you want the Git ecosystem without a one-way migration.
The mechanics — branch detection, authorship mapping, binary handling, and what does and does not survive a Perforce-to-Git conversion in detail — are the same regardless of which host receives the result, and we have already written that up once rather than duplicating it here: see Perforce to GitLab migration: what moves, what breaks, and when not to. Read it even if GitLab is not your target; the tooling section and the “what does not survive” table apply to any Git destination.
How we run a Perforce to Git migration
Assessment
We profile your depot — binaries, lock usage, protect-table complexity, stream topology — and tell you honestly which host and converter fit, and whether migrating is right at all.
Mapping
Depots, streams, protect rules, labels and triggers mapped to repositories, branches and permissions, signed off before anything moves.
Pilot
One depot or stream converted end to end, so the timeline estimate is based on evidence, not a guess.
Full migration & reconciliation
History converted in phases, with counts and spot checks proving what arrived matches what left.
Parallel-run
Perforce kept read-only or actively synced while teams transition, so there is a rollback path.
Training & licensing
Hands-on Git training, plus right-sizing licensing on both the Perforce and Git-host side.
Who we help
- Engineering teams consolidating on one Git host for source, CI/CD and code review, off a standalone Perforce server.
- Studios and media teams deciding whether Git LFS locking on their target host is good enough to replace Perforce exclusive checkout, or whether a hybrid P4 Git Connector approach fits better.
- Regulated and public-sector organizations needing a self-managed or air-gapped Git host to match a compliance boundary Perforce already satisfies.
- Teams evaluating Perforce licensing alongside the move — see our Perforce P4 licensing comparison.
Related migrations: ClearCase to Git, SVN to Git, Bitbucket to GitLab. Or see all our tool migration services.
Frequently asked questions
Which Git host should we migrate to?
It depends on your binary footprint, your locking needs and whether you need self-managed or air-gapped hosting. GitLab and GitHub both offer self-managed/Enterprise Server options with native LFS locking; Bitbucket Cloud has no LFS locking at all (Data Center does); Azure Repos fits teams already standardized on Azure DevOps. We assess your depot before recommending a destination.
Is Perforce still called Helix Core?
Perforce Software renamed Helix Core back to Perforce P4 in 2025, consolidating its tools under the P4 Platform name. The underlying p4d server, file formats and commands (p4 sync, p4 submit, and so on) are unchanged — only the product branding moved.
Does any Git host have a built-in Perforce importer?
No. GitLab, GitHub, Bitbucket and Azure Repos all point you at the same external tooling — git-p4, p4-fusion, or a commercial converter. The choice of host does not simplify the conversion step itself; it changes what the destination can do with the result afterward.
Will Git LFS locking replace Perforce’s exclusive checkout?
For light, occasional use, often yes on the hosts that support it. For a production art pipeline with dozens of contributors, no host’s LFS locking is a full substitute — it is advisory, fails at push time rather than checkout, and (Bitbucket Cloud aside, where it is absent) is enforced server-side only on GitLab Premium/Ultimate default-branch locks.
Can we keep Perforce and Git running side by side?
Yes. The P4 Git Connector lets Perforce serve as a Git remote to any of the four hosts, and a read-only or actively-synced Perforce instance is the cheapest rollback plan while teams get comfortable in Git.
How is this different from your Perforce to GitLab page?
That page is a deep, GitLab-specific breakdown of what git-p4 and p4-fusion do and what does not survive. This page is the decision one level up: which Git host to target, since GitLab, GitHub, Bitbucket and Azure Repos are not interchangeable once large binaries or locking are in play.
Git host repository, push and LFS limits, and LFS file-locking support, verified 26 September 2026 against GitLab, GitHub, Atlassian Bitbucket and Microsoft Azure Repos documentation. Perforce’s P4 rebrand verified against Perforce’s own announcement. Figures change; confirm current limits on the vendor’s site before budgeting. ReleaseTEAM is an Atlassian Gold Solution Partner and a GitLab partner, and sells and supports Perforce.
Pick the right destination before you pick the tool
Tell us what is in your depot — binaries, locks, permission boundaries — and we will tell you which Git host actually fits, then run the migration or the assessment, whichever you need first.
Speak With An Expert