The honest case for Perforce

This article is a counterweight. Most modern engineering blogs assume Git is the answer. For a meaningful set of projects, Perforce is genuinely the better choice. Knowing when is a real engineering decision.

Signal 1: binary-heavy workloads

If your daily commits include FBX models, PSD files, multi-gigabyte WAVs, raw camera footage, CAD assemblies, or compiled engine artefacts, Perforce's design fits the work. Git LFS exists, but the workflow remains second-class - lock acquisition is explicit, server quotas constrain scale, and integration with DCC tools is uneven.

Real-world threshold: if more than half your commits touch unmergeable binaries, evaluate Perforce.

Signal 2: locking is non-optional

If your team has ever lost an artist's day of work because two people edited the same scene, you need locks. Perforce's lock is a first-class concept; Git LFS's is bolted on. The convenience difference is real and felt daily.

Signal 3: per-path access control

If access control questions like "this contractor can see the menu code but not the engine internals" or "this NDA-bound region of the repo is hidden from non-cleared users" arise, Perforce's per-path ACLs save you. Git's per-repository model forces awkward repo-splitting workarounds.

Signal 4: massive monorepo with no clean splits

Game studios, VFX houses, hardware design firms often have one repository measured in terabytes that cannot be split. Source code, art, build artefacts, vendor SDKs - all related, all needing to ship together. Perforce handles this natively; Git requires extensive work (sparse checkout, partial clone, custom tooling) to approximate.

Signal 5: integrated DCC tooling

If your team uses Maya, Unreal Engine, Unity, Substance Painter, Houdini, or similar, all integrate with Perforce out of the box - "Add to Perforce" buttons in their UIs. Git integration ranges from third-party plugins to nothing. For artists who are not engineers, the difference between "click button to commit" and "open terminal, type commands" is the difference between adoption and revolt.

Signal 6: build farm integration

Massive distributed build systems (incredibuild, etc.) often have decades of Perforce integration. Replicating with Git is possible but requires engineering effort.

Signal 7: regulatory and audit needs

Some industries (defense, automotive, medical) require full audit trails of who accessed what. Perforce records this server-side; Git's distributed model fundamentally cannot.

When Perforce is the wrong choice

Push back on Perforce when:

• Your workload is mostly text code that merges cleanly.
• Your team works distributed, often offline.
• Your tooling expects Git (most modern web frameworks, CI services, security tools).
• You are bootstrapping and licence cost is meaningful.
• You want to leverage open-source contributions - public OSS lives in Git.

The hybrid playbook

Many shops run both. A typical setup:

• Perforce for art assets, animations, audio, video, large binaries.
• Git (often GitHub Enterprise) for engine code, gameplay scripts, tooling.
• Build pipelines pull from both; CI signs and ships unified artefacts.
• Code review happens via PRs; art review via Helix Swarm.

# Build script integrating both
#!/usr/bin/env bash
git fetch && git checkout main
p4 sync //assets/release/...
./build.sh

Migration considerations

Perforce-to-Git migrations are common but involve trade-offs. git p4 bridges the systems for transition. Decisions to make:

• Which streams become Git branches?
• How are exclusive locks replaced - LFS, social conventions, both?
• How is per-path ACL replaced - separate repos, server hooks, social?
• How are binary assets stored - LFS, S3, vendor lock?

The take-away

Perforce is not legacy. It serves real needs that Git serves badly. The right tool depends on the work, not the trend.