Migration overview
There are two realistic paths out of Perforce:
- Current-state migration— commit today's workspace into USourceControl as the first version. Keep the old Perforce depot read-only for historical reference. This is how ~90% of migrations work.
- Full history migration — import past changelists into USourceControl so version history is preserved. Requires more work and is available on Studio and Enterprise plans.
Unless you have regulatory or contractual reasons to preserve full history in the new system, current-state migration is the pragmatic choice. You lose nothing — the old Perforce depot stays available — and you get a clean start without legacy baggage.
Step 1: Plan the cutover
Migrating source control mid-project has real coordination cost. Plan for:
- A freeze window (typically half a day for small teams, a full day for 10+ person teams).
- A designated migration lead — one person does the initial commit; everyone else waits until it finishes.
- A communication plan: announce the freeze, confirm everyone has committed and locked nothing, then start.
Step 2: Prepare a clean workspace
On a dedicated migration machine, run one final Perforce sync:
# Get everything up to date
p4 sync ...
p4 revert -a # discard any stray checked-out files
# Verify the depot is at head
p4 changes -s submitted -m 1Clean up unneeded files — anything you don't want carried into the new system. For game projects on Perforce that often includes:
- Build output directories you accidentally added years ago.
- Old streams that aren't used anymore.
- Temp or scratch folders that accumulated per-user clutter.
This is your one chance to start fresh without three years of depot archaeology. Use it.
Step 3: Create the USourceControl project
- Sign up at usourcecontrol.com/signup.
- Create an organization. If you have more than five team members, go straight to the Indie plan — you'll want team collaboration, audit logs, and priority support during migration.
- Create a new project with a matching name.
- Copy the project key.
Step 4: Initial commit (current-state migration)
- Install the desktop app on the migration machine.
- Sign in and link the new project using the project key.
- Point the app at your Perforce workspace root.
- Review the file list carefully. The app will detect your engine (Unreal, Unity, Godot) and suggest default exclusions — accept them, or customize. Typical exclusions:
Saved/ (Unreal)
Intermediate/ (Unreal)
DerivedDataCache/ (Unreal)
Library/ (Unity)
Temp/ (Unity)
.godot/ (Godot)- Commit with a message like "Initial migration from Perforce, changelist 47281" — record the Perforce changelist you synced from for future reference.
Step 5: Mark Perforce read-only
Once the migration commit lands, the Perforce depot becomes your historical reference, not your active source of truth. To prevent accidental writes:
- Remove write access for all users — keep everyone as "readers" in protections.
- Document where to find the depot (server, port, workspace naming) in your team wiki.
- Decide on a sunset date. Many teams keep Perforce running read-only for 6–12 months, then archive the depot to cold storage.
Step 6: Team cutover
Invite teammates to the new USourceControl project. Each person:
- Accepts the invite, installs the desktop app.
- Picks a fresh folder on disk (not their old Perforce workspace) and does the initial sync.
- Opens the project in their engine as usual.
- Validates that everything works (build, play, open key scenes).
Keep the migration lead available for the first 48 hours to handle questions and lock/unlock weirdness.
Optional: Full history migration
If you need Perforce history preserved inside USourceControl — typically for regulatory or contractual reasons — contact us before starting migration.
We'll walk through your depot structure, changelist volume, and any custom workflows (streams, triggers, labels) that need to be accounted for. History migration is a paid service tier on Studio and Enterprise plans, scoped per project.
For most teams this isn't worth the cost or timeline. Keeping old Perforce read-only covers the "I need to look at how we did X in 2022" use case at zero migration cost.
Troubleshooting common issues
First sync on teammates' machines is slow. Expected — it's a full initial download. Subsequent syncs are incremental and fast.
Someone opened their old Perforce workspace instead of the new USourceControl folder. They'll be editing the wrong files. Point them to the new folder explicitly in your migration brief; make the old workspace read-only at the OS level if you need belt-and-braces.
Files that needed locking in Perforce aren't being locked now. USourceControl locking is a workflow — teach the team to use it for binary files (blueprints, scenes, prefabs). It's identical in concept to Perforce exclusive checkout.
Frequently asked
Can I preserve Perforce changelist history?
Yes, as a paid service on Studio and Enterprise plans. For most teams, keeping the old Perforce depot read-only for historical reference is the more pragmatic option.
How long does migration take?
For a 50 GB project with a 100 Mbps upload, the initial commit takes ~70 minutes. Team cutover is usually a single half-day. Larger projects scale linearly.
Do I need to shut down Perforce entirely?
No — keep it running read-only. Historical changelists remain accessible, but active work moves to USourceControl.
What happens to Perforce streams?
Streams don't map one-to-one to USourceControl, which has a simpler project model. If you have meaningful long-lived streams, contact us before migrating so we can advise on the right structure (multiple projects, or flattening).
Can we migrate gradually — some teams on new, some on old?
Technically possible but complicates coordination. We recommend a one-shot cutover during a freeze. For very large studios, a project-by-project migration may make sense.
