Migration over SSH

With Migration › From a server over SSH the panel connects straight to the old server, recognizes what is there (cPanel, Plesk, CWP, DirectAdmin or any Linux), prepares the backup, transfers it and imports it: you do not download or upload any file. For the details of what is imported (sites, files, databases with new passwords, wp-config.php, mailboxes and forwarders, paused cron jobs) see Migration from cPanel and Plesk: the import steps are the same.

Credentials: used once, never saved

You need the address, the port (usually 22), the user and a password or a private key (paste the content, with its passphrase if it has one). The credentials stay in memory only for the duration of the migration: they are never written to disk, to the logs or to the activity log, and they are wiped at the end. If the panel restarts during the migration, the migration stops: simply connect again.

Panel key (no password): choose the Panel key tab and press Create the key. The panel creates a temporary key, valid for 2 hours and kept in memory only, and shows a command to paste in the old server's terminal, as the user you connect with (usually root): it adds the key to ~/.ssh/authorized_keys, with no terminal or forwarding. At the end of the migration, or when you close the session, the panel removes it by itself; if it cannot, the page also shows the command to remove it by hand.

Root credentials give full access to the old server: the panel uses them only for the migration commands (backup, reading the files, database dumps) and removes its own temporary files at the end, even if the migration fails or you cancel it.

The server fingerprint

On the first connection the panel does not send any password yet: it reads the server key and shows you its fingerprint (for example SHA256:…). Compare it with the old server's, from a console you trust:

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

When you confirm, the panel authenticates and pins that fingerprint for the whole migration, final sync included: if the server ever presents a different key (reinstalled server, or someone in the middle), the connection is dropped.

What happens, by server

cPanel as root: "Analyze server" lists the accounts (with domains, space and databases). Choose which to bring: for each one the panel runs /scripts/pkgacct on the old server, downloads the archive, deletes it from the old server and imports it like a full backup file. Administrators find the option Create a panel account for each cPanel account already on: each cPanel account becomes a panel account with the same username, the same contact email and the chosen package (see The user's account); with CloudLinux limits, each gets its own.
cPanel with the account user (no root): the panel reads domains and folders from the account (UAPI), finds the database credentials in the wp-config.php files and copies files and databases directly. Databases without WordPress ask for user and password.
Plesk as root: it lists the subscriptions; for each one it uses plesk bin pleskbackup and imports the backup. If the Plesk backup fails, it copies the subscription's files and databases directly. In the What to import step you can choose the method:
- Plesk backup: complete, with mail, DNS and scheduled jobs. Plesk first writes the backup in its folder (DUMP_D of /etc/psa/psa.conf, for example /nfsbackup) and then copies it into a single archive in /var/tmp: the old server needs free space of about twice the subscription. The analysis checks it and, when it is not enough, says so with the GB needed and the GB free; the panel checks again right before each backup, so the migration does not stop halfway.
- Direct copy: the site files and the databases one by one, with no temporary space on the old server, with the exclusions you choose. Mail, DNS and cron are not imported.

rsync straight into the site's folder (from 0.81, for cPanel, Plesk, CWP and Linux, when the old server has rsync): the files go from the old server straight into each site's folder, with no archive, extraction or intermediate copy. The new server only needs the space of the sites (plus the database dumps), an interrupted transfer resumes where it stopped and the bar shows the real bytes. The databases are copied one by one; mail, DNS and cron are not imported. It is the recommended method for big sites. rsync travels over the panel's SSH connection, with the same server fingerprint and the same credentials, which are never written to disk.

CWP (Control Web Panel) as root: it lists the CWP accounts with main domain, addon domains, subdomains, space and databases. For each chosen account the panel builds on the old server a full package in the format of a cPanel backup: the home with the sites, the databases with their users (and the hashed password, to keep it if you want), the mailboxes with every message and the original password, the forwarders, the cron jobs and the PHP version of each domain. It downloads it, deletes it from the old server and imports it like from cPanel, including the option to create a panel account for each CWP account. If a domain's PHP version is not installed here, the site gets the closest one and the summary says so.
Any Linux or DirectAdmin: the panel suggests the folders that look like sites (public_html, /var/www/…) with their size; choose the ones to bring and give each its domain (you can also add a folder manually). Databases are found from wp-config.php, ~/.my.cnf or root access; for the others enter user and password.

The direct copy uses tar for the files and mysqldump for the databases, inside the SSH connection: nothing needs to be installed on the old server. Database passwords travel only in a private temporary file in the user's home, deleted right after, never on the command line. Symbolic links are not copied (for safety) and the report tells how many there were.

Active and suspended accounts

When choosing the accounts (cPanel and Plesk as root) each one shows its status on the old server: Active (green), Suspended (amber, with the reason the old panel gives, if any) or Disabled (red). Suspended accounts are not selected at first; "Show active only" hides them. If you choose some, the option "Import suspended as suspended" (on by default) imports their sites already suspended: they show the "site suspended" page until you reactivate them from the site page. Untick it to import them active. The migration summary records which accounts were suspended.

Disk space: the migration starts only if it fits

While you choose what to import, a bar shows for each disk of this server the space used, what will be needed and the reserve (10% of the disk, which always stays free: a full disk stops the databases, the mail and the panel). The estimate is prudent: during the import about 2.2 times the data is needed (the archive and its extraction in the temporary area, plus the data in its final place); when sites, databases, mail and the temporary area are on different disks, the sum is made disk by disk.

If the space is not enough, "Start import" stays locked and the panel says on which disk and how much is missing. You can remove some accounts from the selection, free space or add a disk from Server › Disks. The space is checked again right before starting and every few seconds during the transfer: if it drops under the reserve, the migration stops cleanly (the temporary files are removed and the summary shows what had already been created). The check applies to everyone, administrators included, and cannot be skipped.

Risky files in the public folder

The analysis reports the files anyone can download from the main folder of the sites: database dumps (.sql, .mysql), archives and backups (.zip, .tar.gz, .bak) and .env files with passwords and keys. Dumps and archives are not copied (Leave out dumps and archives in Copy of the files, on by default); delete them from the old server too.

Progress and report

The time left appears only once the panel has measured the real transfer speed (after about 30 seconds); before that, during the backup on the old server, it is not shown. The phases that follow are estimated from the size of the data.

After choosing what to import (domain renames, databases, PHP version, cron) the operation starts with its phases: connection, analysis, backup on the source server, transfer (with data transferred, speed and estimated time), extraction, sites, files, databases, configuration, cron, checks and cleanup on the source server. Before starting, the panel checks the free space (about twice the estimated size is needed) and the package limits. The bandwidth limit of the connection form avoids saturating the old server.

The final report is the one of the file migration (sites, database passwords shown once, notes) plus the Next steps. The migration then stays available on its detail page (see Migration from cPanel and Plesk), which also keeps the history of the final syncs.

Switching DNS, step by step

Lower the TTL: where your DNS is managed today, set the TTL of the domains' records to 300 seconds at least a day before.
Final sync: right before the switch press Final sync (in the report or in the "Migrations over SSH" list of the Migration page). Enter the password or key again: the panel compares the old server's files with the migrated ones (size and modification time), copies only the changed ones and re-imports the databases. Files deleted on the old server are not deleted here, and the rewritten configuration files (wp-config.php, .env, configuration.php) keep their new content. It is available for 7 days after the migration.
Point the domains to this server: if you connected a DNS provider (see DNS) open the site and use Point to server, which shows what changes before applying it; otherwise update the A records at your provider. The switch is never automatic.
Keep the old server until the sites answer correctly from here and mail arrives here (with the mail service active, cPanel mailboxes as root arrive with their messages and original password, Plesk mailboxes as root are created; with the account user or from a generic Linux server recreate them). To receive mail here publish MX, SPF and DKIM with Set up mail DNS (see Mail).

Who can do it

Administrators: any server (private or local addresses too) and any target account.
Resellers: servers reachable on the Internet, importing into their own accounts; they may use root on cPanel or Plesk too.
Users: servers reachable on the Internet, importing into their own account within the package limits, and only the direct copy of files and databases (no pkgacct/pleskbackup, which bring whole accounts with root tools).

A migration session belongs to whoever opened it: nobody else, not even an administrator, can use it. Connection attempts are limited (10 every 10 minutes per person) and every connection is recorded in the activity log with user, server and fingerprint, never with the credentials.

Limits

Mail is migrated only with the mail service active and from cPanel, Plesk or CWP as root; with the account user or from a generic Linux server the mailboxes must be recreated. Cron jobs arrive paused for review.
The final sync brings files and databases, not mail: messages that reach the old server after the migration stay there. Change the MX right after the final sync.
The old server needs a POSIX shell (bash, dash, sh) and, for the direct copy, GNU tar, find and mysqldump.
Access through sudo is not supported: use root or the account user.