Move an account off the old server without downloading it

Moving a customer used to mean: sign in to the old host, generate a backup, download several gigabytes to your computer, upload them again. On a home connection that is an afternoon per customer, and it is the single biggest reason people stay where they are.

The Transfer Tool connects to the old server from this server and streams the archive across directly. Admin → Migrate → "Or pull it straight from the old server."

What you need

Two ways to get the archive

Build a fresh cPanel backup. We run cPanel's own pkgacct on the old server, which is exactly what cPanel's transfer tool does — and, like cPanel's, it needs root there. The backup is built into a temporary folder, streamed here, and removed from the old server afterwards: a migration should not leave a copy of somebody's entire account on the machine they are leaving.

An archive that already exists. You name a file on the old server and we fetch it. This is the answer for Plesk, DirectAdmin and anything else: create the backup with that panel's own tool, then point us at the file. We deliberately do not guess at other panels' command lines — a wrong guess would fail in the middle of a migration, which is the worst possible time.

Why it asks you about a fingerprint

You are about to type a root password into a machine identified only by a name you typed. If that name resolves somewhere unexpected — a typo, a stale DNS record, someone in the middle — the password goes to whoever answered.

So the first step only identifies the machine. It connects, shows you the server's fingerprint (SHA256:…) and its SSH banner, and stops. Compare that fingerprint against what the old host shows you. Only then does the transfer form appear, and the transfer refuses to run against a server presenting a different key.

If you have SSH access to the old server, you can print its fingerprint there:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

If the fingerprint changes later, stop. That is either a rebuilt server or somebody in the middle, and both need a person to look.

While it runs

The transfer runs in the background and reports how much has arrived. You can leave the page open; a large account takes a while, and the transfer does not depend on your browser staying put.

One at a time. A second transfer is refused while one is running — two multi-gigabyte pulls competing for the same disk gives you two half-finished ones.

A failed transfer leaves nothing. The archive is only put in place once it has arrived whole. If the old server runs out of disk building the backup, or the connection drops, you get an error and can simply try again — there is no partial file to hunt down and delete.

After it arrives

The transfer stops there, on purpose. The archive lands in the same place an uploaded one does, and the existing steps take over: Preflight shows you exactly what would be imported — account name, domains, databases, mailboxes, PHP version, and any conflicts with what is already here — and Import recreates the account.

Nothing is created until you have read the preflight. The archive is treated as untrusted throughout, whether you uploaded it or we pulled it.

When it will not work

• No root on the old server. Fetch an existing archive instead: generate it in the old panel's own interface (cPanel: Backup Wizard), then point us at the file.
• The old host blocks SSH from outside, or allows it only from listed addresses. Ask them to allow this server's IP, or fall back to uploading the archive.
• Not enough free disk on the OLD server to build the backup. pkgacct needs room for a full copy of the account before anything is streamed. Free space there, or have them create the backup somewhere with room and use the existing-archive path.