This runbook is for administrators upgrading a self-managed Perforce server to the 2014 generation of binaries. It focuses on the exact operational flow from the original guidance: verify first, checkpoint and back up, install the newer binary, replay the checkpoint, then validate again.
Originally published on 2014-09-24; fully revised and updated.

What this upgrade procedure covers
The source procedure emphasizes upgrading by taking an existing checkpoint and replaying it with the newer P4 Server binary (notably relevant when database structures changed in the 2013.3+ era). It also includes validation before and after the upgrade and cautions about platform or architecture changes.
Upgrade workflow at a glance
flowchart TD
A[Check license and release notes] --> B[Run pre upgrade verify]
B --> C{Any BAD or MISSING}
C -- yes --> D[Stop and contact support]
C -- no --> E[Stop server and take checkpoint]
E --> F[Backup db files and archives]
F --> G[Install new p4d binary]
G --> H[Replay checkpoint with new binary]
H --> I[Run schema update command if needed]
I --> J[Start server]
J --> K[Run post upgrade verify]
K --> L[Take fresh checkpoint]
Pre-upgrade validation commands
Run these checks before stopping the server:
p4 license -o
p4 verify -q //... > verify.txtCode language: JavaScript (javascript)
From the original guidance: if verify.txt contains BAD! or MISSING!, contact Perforce Support before upgrading.
If the depot is large and verify fails with a memory-size request error, split verification by depot path:
p4 verify -q //depot/project1/... > prj1-verify.txt
p4 verify -q //depot/project2/... > prj2-verify.txt
p4 verify -q //depot/project3/... > prj3-verify.txtCode language: JavaScript (javascript)
Shutdown, backup, and binary preparation
- Stop the Perforce server.
- Create a checkpoint.
- Copy db.* files to a safe location.
- Back up archive files.
- Read release notes and download the target server binary.
- Confirm downloaded binary version.
p4 admin stop
p4d -r P4ROOT -J journal -jc
p4d.exe -V
p4s.exe -VCode language: CSS (css)
Original links referenced for this stage: release notes and Perforce FTP download location.
Restore on the new binary and validate post-upgrade
After installing the upgraded server binary, replay the checkpoint from the old server. If the checkpoint is compressed, include -z. For larger servers (as noted in the original), run the additional update command when applicable.
p4d -r root -jr checkpoint.xxx
p4d -r P4ROOT -jr -z checkpoint.ckp.104.gz
p4d -r root -xu
p4 verify -q //... > upgrade-verify.txt
p4d -r root -J journal -jcCode language: JavaScript (javascript)
Then start the Perforce service using your normal service-management method for your OS.
Upgrade path comparison
| Scenario | Typical approach | Key caution from original guidance |
|---|---|---|
| In-place upgrade on same host | Stop server, checkpoint, install new binary, replay checkpoint, verify | Do not skip pre/post verify steps |
| Move to new 64-bit hardware | Migrate via checkpoint and restore on new host | Do not run 64-bit binary directly against 32-bit db.* files |
| Cross-platform migration (Linux/Windows) | Treat as a separate migration project, not a simple binary swap | Original note says this is not trivial and may require conflict consolidation tooling |
Reference links from the original guidance
- Upgrading to 2013.3 and beyond
- Upgrading a Perforce Server
- Moving a Perforce Server
- Cross-Server Platform Migration (search URL)
- Cross-Server Platform Migration
- Upgrading the Perforce Proxy
- BTree Format Changed for Perforce Server Versions 2013.3 and Later
- Lockless Reads
- Change Server Request
- Request Background User
Original upgrade notes included support guidance attributed to Chris Lesemann (Perforce Support).
Common pitfalls
- Proceeding when pre-upgrade verify already reports BAD or MISSING revisions.
- Skipping offline backups of both metadata (db.*) and archive files.
- Replaying a compressed checkpoint without the -z switch.
- Mixing 32-bit and 64-bit database/binary assumptions during migration.
- Forgetting the final post-upgrade checkpoint after successful validation.
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.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals