First, work out which failure you're hitting
Git LFS does not break in one way. It breaks in four, and people switch tools to fix a problem they do not have while keeping the one they do.
1. Pointer-file data loss. Assets silently replaced by 130-byte text stubs. Symptom: a texture that opens in a text editor and starts with version https://git-lfs.github.com/spec/v1.
2. Bandwidth billing. Your host meters LFS transfer and sells it in packs. Symptom: a bill that moves without anyone changing how they work, usually traced to nightly build pulls.
3. Repository bloat. Binaries committed outside LFS, or LFS added after the fact so history still carries the originals. Symptom: a fresh clone takes hours.
4. File count. The Unreal Engine 5 one. One File Per Actor gives every placed actor its own small binary, each needing its own pointer. Symptom: git status and branch switching crawl on a World Partition project that was fine six months ago.
Two of these you can fix without leaving Git
Worth trying before a migration, because migrations cost a week and sometimes you do not need one.
Pointer-file loss is a process problem.It happens when a client, a contractor's laptop, or a CI runner is not LFS-aware. Enforce LFS installation in onboarding, add a pre-receive hook that rejects commits where a tracked binary arrives as a pointer, and make sure every CI image installs LFS. That closes it.
Bandwidth is partly a hosting choice. Some hosts meter LFS aggressively and others barely at all. Azure DevOps in particular does not charge for LFS storage, which is why it shows up on these lists despite not being game-specific. Moving hosts is cheaper than moving systems.
Bloat is sometimes repairable. If binaries went in outside LFS, history rewriting tools can retroactively move them. It is disruptive, everyone re-clones, and it only works if you can coordinate a hard cutover. But it is a day, not a migration.
What none of this fixes is the fourth failure. File count is structural: it comes from LFS creating one pointer per binary, and no amount of configuration changes that.
The alternatives, by what they actually fix
Anchorpointkeeps Git and LFS underneath and replaces the interface with something artists will use. Fixes: the usability problem, genuinely well. Does not fix: pointer semantics, your host's bandwidth pricing, or file count, because all three live below the layer it operates on. Right choice if your actual complaint is "my artists hate the CLI".
Perforce Helix Core abandons Git entirely for a centralized model built around large binaries and exclusive checkout. Fixes: all four, including file count, which is why it remains the AAA default for World Partition projects. Costs: a server, an admin, and per-seat licensing that scales badly below enterprise volume.
Lore (Unreal Version Control)is Epic's open-source entry, targeting the same problems as Perforce without the licensing. Fixes: the same four, in principle. Costs: you run the server, and it is new enough that it has not accumulated Perforce's production hardening. Longer take here.
Diversion is cloud-native with an Unreal plugin shipping on Fab. Fixes: all four, with no server to run. Broader focus than Unreal alone, spanning video and VFX.
Plastic SCM / Unity VCS handles large files well and merges better than most. Fixes: bloat and bandwidth. Unreal integration is not first-class, and pricing ties to Unity tiers.
Why One File Per Actor is the one that forces the decision
The first three failures have workarounds. This one does not, and it is worth understanding why before you spend a week trying.
LFS creates one pointer per tracked binary. That is the design, not a setting. When a populated World Partition level produces thousands of external actor files, your Git index grows by an entry per actor, and every operation that walks the index pays for it. There is no configuration that makes LFS stop creating pointers.
The pattern is also getting more common rather than less. OFPA is enabled by default with World Partition, and World Partition is the default way to build an open world in Unreal Engine 5. Teams that were fine during greyboxing hit this during production, which is the worst possible time to change source control.
If this is your failure, the honest answer is that you need something not built on Git. Which one depends mostly on whether you want to run a server. More on what OFPA does to a repository.
Where we fit
We built USourceControl for the fourth failure specifically, so treat this section with the appropriate suspicion.
There is no pointer layer, which removes the first failure by construction: the file you commit is the file stored. Storage and bandwidth are unlimited on every plan including the free one, which removes the second. History lives server-side rather than in every clone, which removes the third. And many small binaries is the normal case rather than an edge case, with hash-based delta sync and up to 25,000 files per commit, which is the fourth.
Where we are the wrong answer: you need data on hardware you own (Lore or Perforce), you want the most mature in-editor integration available today (Diversion's plugin is shipping and ours is still in development), or your project is mostly code and Git is genuinely fine.
The short version
Artists hate the CLI, everything else is fine → Anchorpoint, keep Git.
Bandwidth bill → change hosts before changing systems.
Pointer-file accidents → a pre-receive hook and LFS in your CI image.
Clone takes hours → history rewrite, if you can coordinate a cutover.
World Partition project grinding to a halt → you need to leave Git. Perforce or Lore if you have someone to run a server, Diversion or us if you do not.