ISPmanager 6 is an alternative to cPanel with similar functionality but a more flexible licensing policy and native Nginx support. Moving sites from cPanel does not require complex tools — everything is done through standard backups and imports, but the order of steps matters: skipping the mail or permissions step leaves a working site with broken outgoing mail.

Comparing cPanel and ISPmanager 6

A detailed feature comparison is in the article on ISPmanager 6 vs cPanel; for moving between two servers that are already on ISPmanager, see moving a site between servers in ISPmanager 6.

Feature	cPanel	ISPmanager 6
Site management	Yes	Yes
MySQL/MariaDB	phpMyAdmin	Built-in tool
Mail	Yes (Roundcube)	Yes (Roundcube)
SSL (Let's Encrypt)	Yes	Yes
Nginx + PHP-FPM	No (Apache only)	Yes, natively
Docker/containers	No	Basic support
Price/month (1 server)	$25+	EUR 15-30

Step 1: export from cPanel

# Through cPanel -- Backup Wizard -- Full Account Backup
# Download the .tar.gz account archive

# Or through the CLI on the cPanel server
/usr/local/cpanel/scripts/pkgacct USERNAME /home/backup/

Step 2: create the user in ISPmanager

# In ISPmanager: Users -- Create
# Or through the ISPmanager CLI
/usr/local/mgr5/sbin/mgrctl -m ispmgr user.edit name=myuser passwd=StrongPass123 email=user@example.com package=default

Step 3: move the site files

# Upload the backup to the new server
scp backup-cpanel.tar.gz root@new-server:/tmp/

# Unpack and copy the files
cd /tmp && tar -xzf backup-cpanel.tar.gz
rsync -av /tmp/homedir/public_html/ /var/www/www-root/data/www/example.com/

# Set the permissions
chown -R www-data:www-data /var/www/www-root/data/www/example.com/

Common migration errors explained

500 Internal Server Error right after copying the files — most often a permissions issue: the copied files keep the cPanel account's owner, while PHP-FPM in ISPmanager runs as a different user.
SQLSTATE[HY000] [1045] Access denied for user in the site config after importing the database — the cPanel MySQL user did not travel with the dump; it has to be recreated in ISPmanager with the same name and a new password.
Mail sends but never reaches recipients — the new server has no SPF/DKIM records set up, or an old MX record still points to the cPanel server; check DNS separately from whether the send itself succeeded.
PHP Fatal error: require(): Failed opening required — the cPanel archive uses relative paths that differ from the directory layout ISPmanager expects (/var/www/www-root/data/www/ instead of public_html).

Step 4: restore the MySQL databases

# Find the database dumps in the cPanel backup
ls /tmp/mysql/
# backup-db1.sql.gz, backup-db2.sql.gz ...

# Create the database in ISPmanager (web interface or CLI)
# Import it
zcat /tmp/mysql/db1.sql.gz | mysql -u root -p db1_new

Step 5: move the mailboxes

# Extract the mail from the cPanel backup
ls /tmp/mail/example.com/
# user1/ user2/ ...

# Copy the Maildir to ISPmanager
rsync -av /tmp/mail/example.com/ /var/vmail/example.com/

# Create mailboxes with the same names and passwords in ISPmanager
# (passwords have to be reset -- cPanel only stores hashes)

Mailbox passwords: passwords cannot survive a mail migration — they are stored as hashes that are incompatible between panels. Email users the instructions for setting a new password in advance, before the MX record switches over.

Setting up SSL in ISPmanager

# ISPmanager issues Let's Encrypt SSL automatically
# Sites -- select the domain -- SSL -- Let's Encrypt -- Enable
# Or through the CLI
/usr/local/mgr5/sbin/mgrctl -m ispmgr ssl.edit elname=example.com letsencrypt=on

Comparing mail and file migration methods

Data	Migration method	Risk of loss
Site files	tar.gz + rsync	Low
Databases	mysqldump / built-in backup	Low if the dump is verified
Mailboxes	rsync Maildir	Medium (passwords are lost)
Cron jobs	Manual copy from crontab -l	High (often forgotten)

File permissions: ISPmanager uses a different permission scheme than cPanel. After the move, confirm that PHP scripts can read and write the directories they need (/var/www/www-root/data/www/), or the site will load while uploads or caching quietly stop working.

When this migration route does not fit

A zero-downtime move is required — the full-backup method assumes a pause between the export and the DNS switch; true zero downtime needs a separate scheme running both servers in parallel with a final sync.
The old server uses Apache-specific modules (mod_security rules, custom .htaccess tied to a particular Apache version) — ISPmanager runs on Nginx, so such rules must be rewritten for a different web server, not simply copied.
There are dozens of accounts or more — the manual steps above do not scale; a bulk migration needs a script that automates the export and user creation through the ISPmanager CLI.

How to verify the migration finished successfully

# The site loads directly by the new server's IP (before switching DNS)
curl -H "Host: example.com" http://NEW_SERVER_IP/ -I

# The database is in place and the tables are readable
mysql -u root -p -e "USE db1_new; SHOW TABLES;"

# The mailbox accepts mail locally
echo "test" | mail -s "test" user1@example.com

# After switching DNS -- MX really points to the new server
dig MX example.com +short

If the site responds on the direct IP, the database tables are visible and not empty, the test message lands in the Maildir, and MX points to the new server after the switch, the migration finished without data loss.