Bring an existing server across

Is this the right page?

This page moves data into the platform. If your Perforce server already runs here and you want a copy of it somewhere else, you want Back up and export your data instead.

Before you start

• You are an administrator of the project, and the project does not have a Perforce server yet.
• Your current Perforce server is reachable over SSH from the internet, and you can add a line to a user's ~/.ssh/authorized_keys on it.
• That user can read your entire P4ROOT directory (the db.* files and the depot archives), and rsync is installed on the server.
• You can allow inbound SSH from one address, our transfer address, which the app shows you. In this guide it is 203.0.113.20.
• You have, or can plan, a short freeze of your current server for the final cutover.
• You know which plan the new server needs. The Free plan holds 5 people; a source server with more standard users than that cannot be finalized on Free. See How people are counted.

Two forms of source are accepted, and the platform detects which one arrived:

Create the server in migration mode

Follow Create the server, and in the form choose Bring my server across (Copy an existing depot onto a server we host.) instead of Start fresh. The new server is deliberately not started until your data has landed, so instead of the "being created" banner you see the migration panel straight away.

Authorise us on your current server

The migration panel has two cards. Your new Perforce server shows the address your server will have, with three rows and a Copy button each: P4PORT, SSL fingerprint and Public endpoint. During the migration the server is reachable on a temporary public port, 55123 in this guide; after finalize it moves to the server's permanent port, shown on the Project source control card (1031 in this guide; yours is assigned when the server is created).

On your current server is a checklist of what we need from your side. We issue the SSH key, so you never handle a private key: you install only the public half, and the line we give you is already restricted to our transfer address.

1. On your current server, as its administrator: pick a user that can read your whole P4ROOT

   The user needs read access to every file under P4ROOT, and rsync must be on the server. A dedicated user such as perforce is typical.

2. Add our key line to that user's authorized_keys

   Copy the Key line from the panel and append it to ~/.ssh/authorized_keys for that user. Keep the from="…" prefix: it limits the key to our transfer address.

   On your current server, as the transfer userCopy

   $ mkdir -p ~/.ssh && chmod 700 ~/.ssh
   $ echo 'from="203.0.113.20" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...example... dsl-p4-migration' >> ~/.ssh/authorized_keys
   $ chmod 600 ~/.ssh/authorized_keys
   

   The panel shows the real key. The one above is shortened example text and will not authorise anything.

3. Allow inbound SSH from our transfer address

   Open your firewall for SSH from the address shown in the checklist, 203.0.113.20 in this guide. Our transfer traffic originates from that address only.

Tell us what to copy

The last item in the checklist is the rsync command field. Nothing runs on your machine here: you type one line into the app, press Check command, and we run it from our side. Its shape is fixed: an absolute source path on your server with a trailing slash, and the destination written literally as "$DSL_P4ROOT"/.

rsync -az perforce@p4.oldstudio.example.com:/opt/perforce/p4root/ "$DSL_P4ROOT"/

rsync -az perforce@p4.oldstudio.example.com:/backups/p4-checkpoint/ "$DSL_P4ROOT"/

rsync -az -e 'ssh -p 2222' perforce@p4.oldstudio.example.com:/opt/perforce/p4root/ "$DSL_P4ROOT"/

Choose Check command. If it is accepted the panel confirms what it understood, for example We will connect as perforce@p4.oldstudio.example.com:22 and copy /opt/perforce/p4root/, and Start transfer becomes available. If it is refused, the reason is shown next to the field in plain language; the full list is on Troubleshooting.

Choose Start transfer.

Watch the transfer

The panel becomes a progress monitor titled Sync #1 — copying your depot, with a status pill that reads In progress, an estimated percentage, bytes copied against the running estimate of the total, the transfer rate, an ETA and a file count. Progress is an estimate: rsync discovers files as it goes, so the total can grow while the copy runs.

Your current server can stay live during this copy. Bulk syncs run safely against a running Perforce server, and the final delta at finalize time gives you an exact mirror. You can close the page and come back; large depots can take hours. If the network stalls the pill changes to Stalled — retrying and the transfer resumes on its own. Cancel transfer stops it; a cancelled sync can be started again.

A separate card, Verify it's really your server, shows Your server's host key as we recorded it on first contact. Compare it with your server; a later change fails the transfer rather than being silently accepted.

$ ssh-keyscan -t ed25519 p4.oldstudio.example.com

Copied: re-sync as often as you like

When a sync finishes the panel reads Your data is copied, with the sync number and time, and says how the source was recognised: Imported from a Perforce checkpoint — metadata replayed, not copied. or Imported as a raw copy of your P4ROOT.

Keeping your old server live for now? Choose Re-sync changes any time. Each pass copies only what changed, so repeating it is cheap. Your team can keep submitting to the old server right up until you are ready to switch.

Too many people for the free plan

After each sync the platform counts the standard users in the copied data. On the Free plan, more than 5 blocks the cutover: the card shows an alert titled Too many people for the free plan that reads, for example, This server has 8 people. The free plan supports 5. Remove 3 on your source server and sync again, or cancel and create this server on a paid plan. Finalize migration… stays disabled until a sync brings the count within the limit.

Removing people on the source means deleting or converting their Perforce user accounts there (service accounts do not count), then Re-sync changes. Moving the new server to the Team plan instead is done by creating it again on that plan: a migration cannot change plan in place, so choose the plan before you start when the source has more than 5 people.

Finalize: the one-way door

Finalizing runs one last delta and then brings your new server online with your data. From that point the new server is the server. Before you choose it:

1. Announce a freeze and stop your current server

   Nobody should submit after this point, because nothing submitted to the old server after the final sync is copied. Stop p4d with p4 admin stop or your service manager.

2. Checkpoint source? Take one more checkpoint from the stopped server

   If you are migrating from a checkpoint backup rather than a raw P4ROOT copy, take a fresh checkpoint from the stopped server so the final sync carries the last changes.

3. Choose Finalize migration…

   A dialog titled Finalize the migration? asks you to confirm. It reads: Stop your Perforce server first. We will run one final sync of any remaining changes, then bring your new server online. After this point, changes on your old server will not be copied. Choose My server is stopped — finalize, or Not yet to go back.

If the platform refuses, a notification titled Could not finalize carries the reason, for example finalize refused: 8 people on a free-plan server or finalize requires a completed transfer (migration is transferring); stop your source server, run one more sync, then finalize. Nothing has changed; fix the cause and try again.

The panel then shows Final sync followed by Bringing your server online (Bringing your server online — setting up admin accounts, security, and Swarm. This cannot be cancelled.). If that last step fails, the card reads Your data is copied, but we couldn't bring your server online. We've been notified and will fix it; your copied data is kept. with the reason beneath. The platform retries on its own (We're retrying automatically.); once its retries are exhausted a Retry setup button appears for you to try again. Your old server is untouched either way.

Complete

The panel reads Migration complete with a Ready pill: Your server is live at ssl:p4.starfall.northwind.example.com:1031. The Perforce is ready email goes to the project maintainer, and our transfer access to your old server is retired automatically. There is no new password in it. The email says: Your depot, your users and your permissions came across with your server, so sign in with the Perforce administrator account you already use — your existing passwords still work. On the Free plan it adds: The free plan holds 5 people. If more than five came across with your server, move to a paid plan from the Hosting page to keep them all signing in.

If the hosting page still shows the migration panel for a moment after this, you may see Almost there (Your migration finished but the server details are still publishing. Please refresh in a moment.). Refresh the page.

If it fails or you cancel

A transfer that stops on an error shows The transfer did not finish with the real error text from the transfer, for example ssh: connect to host p4.oldstudio.example.com port 22: Connection timed out. The command becomes editable again, with three buttons below it: Save command, Contact support and Retry transfer. Fix the command, choose Save command, then Retry transfer. Contact support opens an email to us with the context attached. The common causes and fixes are on Troubleshooting.

A sync you cancelled shows Transfer cancelled and can be started again the same way. If the panel shows Migration cancelled, the migration has ended and the new server was never brought online; your old server is untouched.

Copying from another Dev Stream Labs project

A copy between two servers we host needs nothing from you but the choice of source. On the new server's checklist, open Copying from another of your DevStreamLabs servers?, pick the project and server in Server to copy and choose Copy from this server. The list holds your organization's other Perforce servers that are ready and not themselves being migrated.

1. Preparing that server for copying

   We turn on export on the source with a key minted for this copy alone, allowed only from your new server's address inside our network. The card reads Preparing that server for copying (usually a minute or two). The source stays live.

   

2. Ready to be copied over our network

   The card reads That server is ready to be copied over our network. Start the transfer when you like. The transfer is composed against the source's internal endpoint — it never leaves the hosting network and no address of yours is involved. Choose Start transfer.

   

3. Finalize

   Re-sync as often as you like, then Finalize as for any migration. When the new server is online we switch export off on the source again and discard the copy's key.

Both projects must be in the same organization. To copy a server from another organization, use its Backup & Export page and the external steps above.

What we do on your behalf

• We mint an Ed25519 key pair for this migration alone. You install the public half; we hold the private half.
• Nothing you type is executed as a shell command. The platform parses your rsync command into a typed specification and rebuilds it; options that could read or write paths on our side, or modify your server, are refused up front.
• Transfers run with a fixed, safe set of flags; SSH runs in batch mode with only our identity.
• Your server's host key is recorded on first contact and shown to you. If it changes later, the transfer fails rather than continuing.
• Transport errors are retried automatically, up to five times, and a partial file resumes where it stopped.
• When the migration completes, the private key is deleted from our systems. A finished migration leaves no standing credential to your server.