Migration from cPanel and Plesk

The Migration section brings a whole cPanel or Plesk account onto this server starting from its backup file, with no need to reach the old server during the import. Administrators and resellers use it (choosing which account to import into) and users, who import into their own account when the package allows.

First: create the backup on the old server

cPanel: Files › Backup › Download a Full Account Backup. In WHM: Backup › pkgacct. You get a backup-….tar.gz (or cpmove-…) file.
Plesk: Tools & Settings › Backup Manager › Back Up, then Download. You get a .tar (or zip) file containing the backup_info_*.xml index. Plesk Obsidian (18) backups, with their compressed .tzst parts, work too: site, databases, mailboxes with their messages and password, forwarders and scheduled tasks (imported paused).
Alternatively a generic archive with the site files plus an SQL dump works too (.tar.gz, .tar or .zip).

Download the file from the old server and upload it into the panel.

Large backups: from an address or from the server

Uploading from the browser works up to 10 GB. For larger backups, or to skip your computer, the same screen has two more ways:

From an address: paste the direct link to the file (https://, ftp://, ftps:// or sftp://) and, if needed, user and password (for sftp:// an SSH key too). With ftp:// the connection is encrypted when the server allows it, even with a self-signed certificate; with ftps:// the certificate must be valid. The panel downloads the backup in the background and, if the connection drops, resumes where it stopped. The credentials are used for this download only and are not stored. Users can download only from public addresses.
From the server (administrators): first copy the backup to this server, for example with scp or rsync, into one of these folders: /home, /root, /srv, /backup, /backups, /mnt, /data, /tmp, /var/tmp. Then enter the full path of the file. The backup is read where it is: the panel neither copies nor deletes it, not even when you remove the upload from the list.

Backups of several accounts

A backup of a whole server is in practice a set of account backups, and the panel imports them one at a time:

A folder on the server (administrators): enter the path of the folder, for example WHM's backup folder /backup/2026-10-24/accounts. Each archive in the folder (and in its accounts/ subfolder) becomes an upload of its own.
An archive that holds several account backups (for example the WHM backup folder compressed into one file): after the analysis the panel shows the accounts it found and offers Split into one upload per account. The original archive is removed, and each account is analyzed and imported like a single backup.

A Plesk server backup, with several subscriptions in one file, is not split yet: back up each subscription, or use the migration over SSH, which takes them one at a time.

The guided flow

Upload: drop the backup file (or choose the target account, if you are an administrator or reseller). The upload shows its progress.
What we found: the panel extracts and analyzes the archive and shows you the domains (main, addon, subdomains, aliases), the databases, the scheduled jobs, the mailboxes and the total size. Check before proceeding. A backup of 1 GB or more is extracted first, with a bar showing how much has been read, the speed and the time left; if you reload the page, you find it again.
What to import: choose which domains, databases, mailboxes, forwarders and scheduled jobs to import (one by one, with "All" and "None" to go faster), rename the domains if needed, choose the PHP version of each site, what to leave on the old server and what to do with the mail (see below).
Import: a background job runs with step-by-step progress (extraction, sites, files, databases, configuration, cron, checks).
Done: the final report shows the status of each item, the new database passwords (shown only once: save them now) and the post-migration checks (the panel tries to reach each site and detects whether it is WordPress).

PHP version, files left out and mail

In the What to import step:

PHP version per site: every domain has its own choice, already set to the version it used on the old server (from cPanel and Plesk, or, for a Linux server without a panel, from the site's nginx, Apache and PHP-FPM configuration). Only the versions installed here can be chosen: if the old server's one is missing, the panel picks the closest one and says so, with the link to install it from PHP versions.
Copy of the files: three choices, each one on its own, to leave on the old server what the new one doesn't need: logs (.log files, error_log, logs/ folders), backups (folders of the WordPress backup plugins such as UpdraftPlus, All-in-One WP Migration, Duplicator, BackWPup and WPvivid, and the site's backup/ and backups/ folders), caches and temporary files (LiteSpeed and Divi caches, tmp/, .cache/). All three are on to start with; WordPress caches and .git folders are never copied. They apply to the final sync too.
Database users and passwords: with Keep the old server's database users and passwords (on to start with) every database keeps its name, user and password: the panel reads them from the site's configuration (wp-config.php, configuration.php, .env) or, from cPanel backups, the hashed password. The site's configuration and external scripts don't change. If a name is already taken on this server or the password isn't available, that database gets new credentials and the summary says so.
Mail: Sites and mail, Everything but the mail (the mailboxes stay on the old server) or Only the mail (mailboxes and forwarders; a domain without a site here gets an empty site, with no files or database, because the mail needs one). Below the choice are the list of mailboxes and the list of forwarders: untick the ones you don't want to bring here, they stay only in the backup.

Two settings the files alone would lose come from the old server too. www alias: the new site of a main, addon or parked domain also answers on www. (as on the old panel, and like a site created here with "www"); subdomains don't. If www. is already used by another site, the report says so. PHP memory_limit: if it was higher than the default on the old server, the site gets it in its PHP settings. The panel reads it from the domain's PHP settings on Plesk, from MultiPHP Manager on cPanel (userdata/<domain>.php-fpm.yaml) and from the php_value memory_limit lines of the .htaccess, which PHP-FPM would ignore here. A .user.ini is copied with the files and works as it is.

During the import, under the phases, there is the list of the sites (of the old server's accounts first, during backup and transfer) with the state of each: done, running with its phase, waiting or error. If you leave and come back while the migration runs, the detail page shows the same progress and the summary appears at the end.

The user's account

Every cPanel backup belongs to a user (the name in the file, for example cpmove-mario). For administrators the "Import into account" choice first offers New account "mario" (as on cPanel): the panel creates the account mario, with the cPanel contact email and the package you choose, and puts the sites, databases and mailboxes there. If mario already exists as a user account it is used; if the name belongs to an administrator or a reseller, the import stops without touching anything.

No email is sent to the user: you usually migrate before moving the DNS. Once the sites answer from here, open the account, press New password and choose Send the "set password" link.

For every other source (Plesk, DirectAdmin, CWP, any server, from a file or over SSH) administrators find New account…: type the username (the panel suggests the one of the main domain, for example grossetosport), the user's email if you know it, and the package. The account is created when the import starts and the sites go there. If you leave Administrator, the sites stay yours: no resource limits, and they are not listed in Limits & usage until you give them to an account.

A site already imported into the wrong account is moved from its page, with the Owner account choice.

The summary of every migration

Every migration (from a file or over SSH) stays listed in Migration and opens a detail page, kept across panel updates: source file or server, who started it, start, end, duration and outcome, the steps with their times and the data transferred, and what was found on the old server. For each site it shows the source and new folder, the files copied and their size, PHP and SSL; for each database size, tables and user; for each mailbox messages, space and whether the password was kept; with links to what was created. The DNS zones found are listed, and if a database the old panel lists is missing from the backup the summary says so. SSH migrations also keep the history of the final syncs. New passwords are never kept: to take it off the list use "Remove from the list".

What the import does: it creates the sites (alias domains become aliases of the main site), copies the files into each site's folder as the site user, creates databases and users with new passwords, imports the dumps into the target database, and rewrites the credentials in the common config files — wp-config.php reliably, configuration.php (Joomla) and .env (Laravel) best-effort, with a note when it is worth checking manually. Scheduled jobs are imported paused, so you review them before enabling.

Final sync

The changes made on the old site after the backup (posts, comments, orders, uploaded files) come here before switching the DNS. From 0.81, the detail page of a migration from a file has Link the old server: address, user and password, private key or panel key, then the confirmation of the server key fingerprint. The panel recognizes the source panel and finds the folders of the domains and the access to the databases; from then on the migration has the same Final sync as the migrations over SSH (see Migration over SSH), for 7 days after the import. The credentials are not saved: they are typed again at every sync.

Disk space

Before extracting the archive and again before the import the panel checks that there is room: the extraction takes about 2.5 times a .tar.gz or .zip archive, and every disk always keeps 10% of its size free. If it is not enough, the import does not start and the panel says how much is missing and where (see Migration over SSH for the space bar and Disks to add a disk).

Security

Backup archives are treated as untrusted: extraction blocks paths escaping the folder (.., absolute paths, links pointing outside), zip bombs (limits on total size and file count), special files (devices, fifos) and strips setuid bits. SQL dumps are sanitized before import: DEFINER clauses are removed, and statements touching other databases (USE, CREATE DATABASE, names with another schema), CREATE USER and GRANT are rejected. The dump can therefore only populate the single target database, imported with that database's own credentials.

Mailboxes

Mailboxes are imported when the mail service is active: from cPanel with all their messages, their original password and the forwarders, from Plesk with a new password when the backup's one cannot be imported (see Mail). With mail off the administrator can enable it together with the import ("Enable mail and import the mailboxes"), or import them later from the migration details ("Import skipped mailboxes"); the Only the mail choice imports only mailboxes and forwarders (see above). If you can connect to the old server over SSH you do not even need to download the backup: see Migration over SSH.