Migration from cPanel and Plesk
Switch panels without starting over.
KoaPanel brings websites, files, databases, cron jobs and mailboxes to the new server from cPanel, Plesk, CWP, DirectAdmin or any Linux box. From the backup file, or by connecting straight to the old server over SSH.
Three ways
Choose how to bring your sites.
From a WordPress site
From any host, even without SSH: all it takes is the address, user and password of wp-admin.
- SiteGround, Hostinger, Aruba… and any other host
- The panel copies files and database with a temporary plugin, then deletes it
- If something is needed from you (verification code, captcha, firewall) it tells you what to do
From the backup file
No access to the old server is needed during the import.
- cPanel: Files › Backup › full account backup (or
pkgacctfrom WHM) - Plesk: Tools & Settings › Backup Manager
- Or an archive with the site files and an SQL dump
- Large backups: from an address (https, ftp, sftp) or from a file already on the server, with automatic resume of the download
- DirectAdmin: the user's full backup, with sites, databases, mailboxes with their original password, forwarders, cron and DNS
- Several accounts: a WHM backup folder or an archive with several accounts: choose the accounts and the destination of each, and one job imports them all
- Upload in pieces: if the connection drops it starts again by itself, with no size limit
Directly over SSH
The panel detects the server, prepares the backup, transfers it and imports it: nothing to download or upload.
- cPanel as root: pick accounts, one or all; with the hybrid method configuration and databases from the cPanel backup, files and mail with rsync
- cPanel with the account user: even without root
- CWP as root: whole accounts, with the mail and the original passwords
- Plesk as root: Plesk backup or direct copy of files and databases, with a check of the space on the old server
- DirectAdmin as administrator: the DirectAdmin backup of each chosen user
- Any Linux: files and databases
- It stops? It resumes: an interrupted migration starts again from where it was, without duplicates
- Big sites: copy with rsync straight into the site's folder, with no archives or intermediate space; an interrupted transfer resumes
The guided flow
Review everything before importing.
What we found
Main and addon domains, subdomains and aliases, databases, cron jobs, mailboxes and total size.
What to import
Choose domains, databases, mailboxes, forwarders and cron jobs one by one, rename domains if needed, set the PHP version and the target account, even a new one.
Import
In the background, step by step: sites, files, databases, configuration, cron, checks.
Final report
Status of every item, new database passwords and a check that every site responds.
What gets migrated
The site works right away, with the right credentials.
- Sites with their aliases, www. included; files copied as the site user
- The old server's PHP memory_limit (Plesk settings, cPanel's MultiPHP Manager,
.htaccess) - Databases and users with new passwords, rewritten in
wp-config.php; Joomlaconfiguration.phpand Laravel.envon a best-effort basis, with a note when worth checking - Scheduled jobs imported paused, to review before enabling
- Mailboxes when mail is enabled: from cPanel with messages and original password
- Final sync over SSH up to 7 days later, right before the DNS switch, also for migrations from backup files: changed and deleted files, databases with the old WordPress sites in maintenance, mail arrived meanwhile
Check and cutover
Know it works before you change the DNS.
Check before copying
For each site the risks already visible: a missing PHP version, files encoded with ionCube, .htaccess rules, paths of the old server, very large databases.
A traffic light for every site
At the end the panel compares the home page and up to 10 pages on the old and the new server, checks resources, PHP and nginx errors, WordPress and leftover paths: works, to check or does not work.
One-click cutover
Final sync, check, DNS change only for the sites that work, SSL certificates and cron: now or at night, at a time you choose.
Administrators can also ask the AI what is wrong with a site to check and apply the proposed fixes with one click, with a preview and undo.
Security
Migrate without taking risks.
Credentials never stored
SSH passwords and keys stay in memory only for the migration: never on disk, in logs or in the activity history. Or no password at all: paste a temporary panel key on the old server, also used by the final sync and removed at the end.
Server fingerprint
Before sending any password it shows you the old server's fingerprint and pins it for the whole migration.
Untrusted archives
Blocks paths escaping the folder, zip bombs and special files; SQL dumps stripped of DEFINER, GRANT and references to other databases.
Migration questions
Do I have to shut down the old server?
No. Keep it running until the sites respond well from the new server and mail arrives there. You decide when to switch DNS: with Complete the cutover the panel does it, when you want, only for the sites the check says work.
How do I avoid losing orders or comments?
Lower the DNS records' TTL a day before, then right before the switch use Final sync: it copies only changed files and re-imports the databases.
Can my customers migrate by themselves?
Yes, within their package limits: users can import into their own account (direct copy of files and databases), resellers into their customers.
Do I need to install anything on the old server?
No. The direct copy uses tar and mysqldump inside the SSH connection; the panel cleans up its temporary files at the end.
Ready to switch panels?
Free up to 3 websites for personal use. When you grow, pick the right plan: every feature is included in every plan.