Koapanel
IT Try it free
All manual sections

DocumentationMigration over SSH

Migration over SSH

With Migration › From a server over SSH the panel connects straight to the old server, recognises what is there (cPanel, Plesk, 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, 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.

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: "Analyse 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.
  • 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.
  • 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 by hand). 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.

Progress and report

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.

Switching DNS, step by step

  1. Lower the TTL: where your DNS is managed today, set the TTL of the domains' records to 300 seconds at least a day before.
  2. 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.
  3. 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.
  4. Keep the old server until the sites answer correctly from here and mail arrives here (cPanel mailboxes as root are imported with their messages when the mail service is active; from a generic Linux server recreate them).

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 clients; 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 not migrated; cron jobs arrive paused for review.
  • 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.