Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Move between machines of the same byte order

If the architecture of the two machines uses the same byte order, such as

Computer Architecture | Byte Order
--- | ---
SPARC/SPARC | big-endian
Windows x86/x86, x64/x64, or x86/x64 | little-endian

the versioned files and database can be copied directly from the old machine (original machine) to the new machine (target machine).

This process involves stopping the server (Step 6), so choose a time that has minimal impact on your users.

Step | Instructions
--- | ---
1. Update the license file. | If the IP address of the new machine is different from the old machine and the P4 Server license is current, obtain a new license file to reflect the new IP address. Fill out a Change of Server Request.
2. Install P4 Server on the new machine. | Install the P4 Server software on the new machine. Use the same release on the new machine as on the old machine. However, we recommend that you to use the latest patch of that release from the download page for P4 (P4D) Server.
3. Locate the versioned files. | By default, depots that contain the versioned files Source files stored in the depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'. that the server manages are located relative to the `P4ROOT` directory. To see the location of the root directory, run `p4 info` and look at the value for `Server root`. Depots might be located elsewhere, so do the following: Run `p4 configure show server.depot.root` If a path is shown, make sure that the depots locations are relative to that path. Get the list of depots by running the `p4 depots` command. For each depot listed, run the `p4 depot -o depotName` command. Look at the `Map` field for the location of the depot versioned files. Make sure that all relevant file systems are mounted. Check for any symlinks that might correspond with depot paths.
4. Verify the versioned files. | Make sure that there are no missing or corrupted versioned files. Make sure that the command syntax for your operating system console or shell captures standard error (stderr) to the output file. Run the p4 verify command on the old server: `p4 verify -q //... > verify.errors 2>&1` If you use shelving: `p4 verify -q -S //... > verify.shelf.errors 2>&1` If you unload data, such as clients and labels: `p4 verify -q -U //... > verify.unload.errors 2>&1` If you use an archive depot to archive file revisions: `p4 verify -q -A //... > verify.archive.errors 2>&1` Examine the output files. If the files are empty, no errors were found. If any errors are listed, see How to Handle p4 verify BAD Errors and MISSING! errors from p4 verify at the Perforce Support Center.
5. Compute missing checksums. | To provide signatures for any files that do not already have them, on the old server, run the following command: `p4 verify -qu //... > verify.update 2>&1` This allows all revisions of all files to be verified by using p4 verify after the move in Step 11.
6. Stop the server. | Run `p4 admin stop` to shut down the old P4 Server. This will prevent access to the server while it is being relocated.
7. Copy the versioned files to the new machine. | Copy over the versioned files from the old machine to the directory on the new machine. Files and directories can be moved using rsync, tar, ftp, a network copy, or any other method that preserves the files as they were on the old server. #### On Unix servers Run rsync (or the equivalent).
    cd old-server-P4ROOT
    rsync -avz ./depot perforce@gabriel:/home/perforce
where `./depot` is one of the directories to be copied on the old server, `perforce@gabriel` would be replaced with the user and hostname of the new server, and `/home/perforce` is the root directory on the new server. Copy over all the versioned file directories. Note the following: Any directory size differences on the new server versus the old server are explained in the third-party post, #rsync FAQ. It is possible to copy most of the files before the server move, then update the versioned files later. To update the versioned files, run the same rsync command. The rsync flags used by this command will only transfer files updated since the command was last run. #### On Windows servers Run xcopy (or the equivalent):
    cd old-server-P4ROOT
    cd depot
    xcopy *.* S:\perforce /s /d /c /e /i /h /y
where `S:\perforce` represents the network drive that contains the corresponding directory on the new server. Copy over all the versioned file directories. It is possible to copy most of the files earlier, then update the versioned files later using the `/d` or `/d:mm-dd-yyyy` option. To learn more, see the Microsoft article about the xcopy command.
8. Install the new license file. | Copy the new license file into the new P4 Server `P4ROOT` in place of the old license file.
9. Rebuild the database files. | Do not remove any files from the old server until you are confident that the new server is in a good state. 1. On the old machine, take a checkpoint A backup copy of the underlying metadata at a particular moment in time. A checkpoint can recreate db.user, db.protect, and other db.* files. See also metadata.. The checkpoint creates a checkpoint file, `checkpoint.n`, along with an associated `checkpoint.n.md5` file that can be used to validate the checkpoint file. The checkpoint file will be used to rebuild the database (`db.*` files) in the `P4ROOT` directory on the new machine. Creating and restoring a checkpoint provides a rudimentary validation of the database. To learn more, see Checkpoint files. To take a checkpoint, run this command on the old machine:
    cd old-server-P4ROOT
    p4d -r old-server-P4ROOT -J D:\perforce\journal -jc
where `D:\perforce\journal` represents the directory path and name of the journal. After the checkpoint operation completes successfully, copy the checkpoint file from the old server to the `P4ROOT` directory on the new server. 2. Before restoring a checkpoint, on the new machine, erase any existing `db.*` files, as well as any `*.lbr` files, any journal or log, any state file, and the `server.locks` directory. Make sure that you are erasing `db.*` files from the new `P4ROOT` on the new machine and not the old machine you are moving from. On UNIX, open a terminal window and restore the checkpoint using:
    cd new-server-P4ROOT
    rm db.*
    rm *.lbr
    rm -r server.locks
    p4d -r new-server-P4ROOT -jr checkpoint
On Windows, open a command prompt and restore the checkpoint using:
    cd new-server-P4ROOT
    erase db.*
    erase *.lbr
    rmdir /s server.locks
    p4d -r new-server-P4ROOT -jr checkpoint
3. If you use LDAP or Active Directory, copy the ldap directory from the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. to the replica.
10. Start the new server privately. | This step is optional, but recommended to prevent unwanted connections while performing work on the new server. Use `localhost` for the P4PORT setting when starting the server. This will deny remote connections while allowing access from the server host itself. Alternatively, start the server on a non-standard port such as `1234` For example, open a command prompt and run: `p4d -r new-server-P4ROOT -p localhost:1234` or `p4d -r new-server-P4ROOT -p 1234` This will start the server listening for network connections. Be aware that the command prompt will not return. See Start the P4 Server and Configure the server. In a separate command prompt, check that that the most recent dates, times, and changelist numbers submitted to the old server are present on the new machine by running this command: `p4 -p localhost:1234 changes -t -m 10`
11. Verify versioned files on the new server. | To ensure that all archive files A special depot into which versioned files (also known as archive files) can be transferred. See also 'depot'. were copied successfully, verify the versioned files on the new server that same way that you did on the old server. See Step 4. Verify the versioned files.
12. Check three variables. | Check whether the `P4ROOT`, `P4LOG`, and `P4JOURNAL` variables on the old server have the default values. If not, follow the instructions of Moving Helix Core Server Components on the Same Machine at the Perforce Support Center.
13. Stop and restart the new server. | Stop and restart the new server using the production host and port number to allow full access. 1. To stop the server, run the `p4 admin stop` command. On Unix, start the server using startup scripts copied over from the old server. On Windows, start the server under Services. 2. Stop the old server. 3. Change the port number on the old server so users will not accidentally connect to the wrong server. For example, `p4 set -S Perforce P4PORT=1234`
14. Check for any automated processes that might access the new server. | Check for the following to see if any need to be updated, migrated, and tested: Custom triggers - Check for any changes in executable and script paths and dependencies, such as the version of Perl or derived APIs, such as P4Perl. Daemons - Check daemons, such as the review daemon or p4thumb. Cron jobs or scheduled tasks - Check automated backup or checkpointing scripts. Startup Scripts - Check P4 Server startup scripts. Anti-virus software and backup scripts - Make sure to exclude the database (`db.*`) and versioned files directories. Other servers - Change Proxy servers, Replica servers, P4Broker servers, P4DTG servers, and so on to point to the new server. This will include modifying the P4TARGET and re-logging service users into the target server. DNS IP adddresses and reverse DNS entries - If the name server name or alias name of the new machine is different, users will likely need to change their P4PORT settings to point to the `new-server:port` P4 client software defaults to connecting to a server named `perforce` at port `1666`. So, if the P4 Server is run on the default port of `1666` with a name service alias for the machine running the server set to `perforce`, users never need to set `P4PORT`. In that case, when changing the machine running the P4 Server, have the IT department update the company name server (DNS) and reverse DNS entries so that the name record `perforce` refers to the new machine rather than the old.
15. Notify users. | Notify your users: That the server is available again. Of any changes to the IP address, server name, and port number so they can update their client applications, such as P4V, Eclipse, Visual Studio, P4EXP.

Your search for returned results