How to Move a Site When the New Host Only Offers cPanel

You can move a website to a new host cPanel account even when the old host runs something else entirely, because the transfer is really just files, a database dump, a DNS zone, and mailboxes moving over ordinary protocols. Nothing about the destination panel limits you: cPanel is a convenient wrapper around things you can do by hand, and the manual route is often cleaner than a migration plugin because you can see every step and stop halfway if something looks wrong.

The one rule that governs everything below is that the old host stays live until the new one answers correctly on a test URL. Do not touch DNS until that is true. Once you delegate the domain, the old panel becomes a read only archive and any mistake costs you a second outage.

Get the files across before anything else

Start by asking the old host for a full backup if the panel offers one, but do not depend on it. If the two panels are different, the archive may not import cleanly, and you will end up unpacking it by hand anyway. The reliable path is a direct copy from old server to new. If the new host gives you SSH access, log in there and pull the tree with rsync. Pulling rather than pushing means you never have to store old credentials on the new machine.

rsync -avz --delete \
  -e "ssh -p 22" \
  [email protected]:/home/user/public_html/ \
  /home/user/public_html/

The output is one line per file, ending in a summary you should read rather than skim:

sending incremental file list
index.php
assets/css/site.css
sent 48213 bytes  received 912 bytes
total size is 15300822  speedup is 311.4

If the old host has no SSH, use its panel file manager to produce a tarball, download it over SFTP, and unpack it on the new side. Watch for two things that break more migrations than anything else: file ownership and permissions. After unpacking, directories should be 755 and files 644, and the owner should be your new account user, not whatever numeric uid the archive recorded. Run find . -type d -exec chmod 755 {} \; and the file equivalent, then fix ownership with chown -R user:user. Skip this and you will see a blank page with a permissions error buried in the log.

Move the database with a consistent dump

A live MySQL or MariaDB database changes while you copy it, so take the dump rather than copying the raw files. mysqldump with --single-transaction gives InnoDB tables a consistent snapshot without locking writes, which matters if the old site is still serving traffic.

mysqldump --single-transaction --routines --triggers \
  -u dbuser -p dbname > dbname.sql

Then create the database and user in the new cPanel under the MySQL section, import the dump, and edit the application config. That config file is where the panel mismatch usually shows up. The old host may have used environment variables, a .env file, or a hardcoded wp-config.php; the new cPanel will hand you a database name prefixed with your account name, something like account_dbname, plus a separate user that must be added to the database with all privileges. Do not assume the old credentials carry over. Update the host to localhost unless the new host documents an external database endpoint.

One more trap: character sets. If the dump was taken from a server defaulting to utf8mb4 and imported into one defaulting to latin1, accented text turns to mojibake. Add --default-character-set=utf8mb4 to both the dump and the import, and check the table collation after import rather than trusting the defaults.

DNS is the last step, not the first

Before you delegate, make the new server answer for the domain without touching public DNS. On your own machine, add a hosts entry pointing the domain at the new IP and browse the site. This is the only honest test, because it exercises the real virtual host, the real rewrite rules and the real TLS certificate.

203.0.113.10  example.com
203.0.113.10  www.example.com

If the site loads and the certificate validates, you are ready. Lower the TTL on your existing A and AAAA records a day ahead so the change propagates quickly, then switch the records to the new address. Keep the old host running for at least the length of the old TTL. Verify propagation by querying an authoritative server directly rather than a resolver that may be caching:

dig +short example.com @ns1.example.net
dig +short MX example.com @ns1.example.net

Mail is the part people forget. If the domain used the old host's mail servers, the MX records must move too, and every mailbox has to exist on the new side before the switch or mail bounces. cPanel can create mailboxes, but it cannot import them from a foreign panel. Copy the mail directory over SSH or use imapsync to pull messages from the old server's IMAP endpoint into the new one. Do the mailboxes first, verify with a test send, and only then move the MX record. Also carry over the SPF, DKIM and DMARC records exactly as they were, because a missing DKIM key will quietly send your mail to spam folders for weeks.

What to check before you delete the old account

Click through the whole site on the new host using the hosts file trick, including forms, search, and any page that writes to the database, because read only pages will not reveal a broken database user. Check the error log for missing extensions such as imagick or intl, which cPanel installs only on request. Confirm that scheduled jobs moved: cron entries do not transfer between panels, and a backup script that silently stopped running is a problem you discover months later. Leave the old account in place, unpaid or suspended if you must, until the site has run clean through at least one full traffic cycle.

If you are partway through this and something is failing, resist the urge to change DNS to see if that fixes it. Work the problem on the new server with the hosts file override, because that isolates the fault to the new configuration instead of spreading it across two systems. When the site answers correctly there, you have finished the migration; the DNS change is just bookkeeping.