Before you start
Write down what you have. For each account: its domains and subdomains, its databases, its mailboxes, its cron jobs, its SSL certificates and anything that depends on Apache rules in a .htaccess file.
Use a second server. Do not install RespireCloud on the cPanel server: the installer's checks look for another panel and for hand managed web, database, mail or DNS servers, and stop on them. A new server of one of the supported systems costs a few days of rent, and it is what lets you test first.
- Ubuntu 22.04, 24.04 and 26.04
- Debian 12 and 13
- AlmaLinux 9 and 10
- Rocky Linux 9 and 10
Lower the DNS time to live a few days ahead
The time to live (TTL) of a DNS record is how long other networks keep an answer. If it is a day, a change takes up to a day to reach everyone. Lower it to a few minutes at least as long as the old value before the day you switch.
Make a backup of one account on cPanel
cPanel's pkgacct script creates a cpmove archive for an account, which is the archive the RespireCloud importer reads. You can also create a full backup from cPanel's own backup tool.
Start with the smallest account you have. Keep the original running: nothing in this guide changes it.
Install RespireCloud on the new server
The installer checks the system first (the system, memory, disk, the host name, free ports, another panel) and verifies the release it downloads before it installs it. The install guide lists the sizes.
Upload the archive and read the report
Open the import wizard and upload the archive. The upload resumes if the connection drops and shows the archive's checksum. The archive is treated as hostile: path tricks, links that leave the folder and decompression bombs are refused.
Before anything is created, the report lists every item as converted, converted with a change or skipped, each with the reason. Read the skipped items first.
- Brought over: the account and its contact, domains with their document roots and PHP version, the home folder, MySQL and MariaDB databases with their users, mailboxes with their mail, forwarders and the catch-all, the DNS zone and certificates
- Not brought over: mailbox and database passwords (hashes cannot be installed), PostgreSQL databases, FTP accounts, autoresponders. Cron lines are listed for review
Run the dry run and test the copy
The dry run builds the account and checks it: each site is fetched over HTTP on the new server and each mailbox is probed over SMTP. DNS and certificates are held back until you commit.
Look at the site yourself, with a hosts file entry that points the domain at the new server. Apache .htaccess rules and PHP ini overrides are not translated, so this is where a site that depends on them shows itself. Mailboxes need a password reset, and database users get a new password kept in the vault.
Commit, or roll back
Commit creates the DNS zones and uploads the certificates. If you do not like what you see, a rollback deletes everything the import created: accounts, domains, zones, mail domains, databases, users, certificates and the home folder. A failure in the middle rolls back by itself.
Bring what changed, then switch DNS
Between the first copy and the switch, the site changes: orders, uploads, new mail. A live transfer over SSH can run a final pass that brings what changed since the first copy, and gives a DNS checklist for each domain. It connects out to the old server, only reads, and pins the server's host key after you confirm it.
Change the DNS records one domain at a time. Keep the old server running until the TTL has passed and mail has stopped arriving there.
After the move
Tell mailbox owners to set a new password. Check the cron lines the report listed. Add a backup target and run a restore of one file before you rely on it.
- Does the site answer on its real name, over HTTPS?
- Does a mail sent to a mailbox arrive, and can it be sent from?
- Did the cron jobs run?
- Is a backup made, and did a test restore work?