Perforce Depot Migration Between Servers Without Losing History or Changelists

Moving a Perforce depot to another server is not just a file copy task. If you need history, metadata, and changelist continuity, you must migrate server data carefully. This guide is for Perforce administrators and DevOps engineers who need a safer, structured migration approach based on the original post and its references.

Originally published on 2011-12-23; fully revised and updated.

What this migration must preserve

When teams ask for depot migration, they usually mean all of the following:

• Depot file content
• File history
• Changelist records
• Usable server metadata after cutover

The original article emphasizes avoiding history loss and mentions cleaning unnecessary data before merge, then using Perfmerge++ for combining repositories.

Migration options and trade-offs

Recommended high-level workflow

flowchart TD
    A[Take full backup and checkpoint] --> B[Create isolated staging copy]
    B --> C[Remove unwanted depot data]
    C --> D[Delete redundant changelists]
    D --> E[Run repository merge step]
    E --> F[Validate history and changelists]
    F --> G[Cut over to destination server]

Example command sequence for staging and cleanup

Use destructive commands only on a validated backup or staging clone first. The original post explicitly mentions checkpoint backup, changelist cleanup with p4 change -f -d, and obliteration of unwanted data.

# 1) Take a checkpoint or full backup from the source server
p4 admin checkpoint

# Alternative style often used in server administration contexts
p4d -r /p4/root -jcCode language: PHP (php)

# 2) Remove redundant changelists (example from original guidance)
p4 change -f -d 12345Code language: PHP (php)

# 3) Remove unwanted depot data before migration (destructive)
p4 obliterate -y //depot/legacy-product/...Code language: PHP (php)

After merge or restore, validate that expected paths, history, and changelist visibility are present.

# Basic post-migration checks
p4 files //depot/target-product/...
p4 changes -m 20 //depot/target-product/...
p4 filelog //depot/target-product/path/to/keyfileCode language: PHP (php)

What Perfmerge++ is, based on the original references

According to the original article, Perfmerge++ merges two Perforce repositories into a third repository and replaced an older script (perfmerge2.pl). The post also states that Perfmerge++ works directly with database files to generate merged database output, rather than operating on checkpoints alone.

Because this tooling and documentation are old, confirm current support status and exact usage in up-to-date Perforce documentation before production use.

References from the original post

• http://kb.perforce.com/article/911
• ftp://ftp.perforce.com/perforce/tools/perfmerge/perfmerge.html

Common pitfalls and safeguards

• Do not run obliterate first on production; always stage and verify.
• Keep immutable backups and checkpoints before each destructive step.
• Validate both content and metadata (files, filelog, changelists), not just file presence.
• Plan rollback and cutover timing before final destination switch.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.