How to Take a Full cPanel Backup and Restore It on Another Server Safely

If you are planning to move your websites, emails and databases from one hosting server to another, a full cPanel backup is the safest starting point. Done correctly, it gives you a snapshot of your entire account: site files, MySQL databases, email accounts, DNS zones, cron jobs and more. Done carelessly, it can mean corrupted restores, missing email history or SEO-impacting downtime during DNS changes. In this guide, we will walk through how we at dchost.com approach full cPanel backups and restores when migrating customers to a new server. You will see not just which buttons to click, but also how to prepare both servers, how to handle DNS and email cutover, and how to test the restored account before you switch traffic. Follow these steps and your cPanel-to-cPanel move becomes a controlled, low‑risk operation instead of a stressful guessing game.

What a Full cPanel Backup Actually Includes (and Why It Matters for Migration)

A full cPanel backup is different from the partial backups you may have used for just files or just databases. When you generate a full backup, cPanel packages almost everything about your account into a single archive that can be restored on another cPanel server.

Typically, a full cPanel backup contains:

• Home directory files: Your public_html (or document root) for all domains, plus any other folders under your account.
• MySQL/MariaDB databases: All databases and their users, including permissions.
• Email accounts and mailboxes: Mail data under each domain, including folders and read/unread flags.
• Forwarders, autoresponders and filters: Per-account and global email routing rules.
• DNS zones (if DNS is hosted on the cPanel server): A, CNAME, MX, TXT and other zone records.
• Cron jobs: Scheduled tasks configured in cPanel.
• SSL certificates and keys: Certificates installed via cPanel (including AutoSSL/Let’s Encrypt, if active).
• FTP accounts and settings: Extra FTP users you have added.

This is why a full backup is the preferred format for cross‑server cPanel migrations: you can restore the account on the new server in one operation instead of re‑creating everything by hand.

If you want a more general overview of backing up and restoring cPanel accounts (including partial backups), you can also read our detailed full cPanel backup and restore guide for files, databases and emails. In this article, we will focus specifically on moving that full backup to a different server safely.

Preparing Both Servers for a Safe cPanel Migration

A smooth restore starts before you generate the backup. A few checks on the source and destination servers can save hours of troubleshooting later.

1. Check cPanel and PHP/MySQL compatibility

• cPanel versions: Ideally, the destination server runs the same or a newer major version of cPanel/WHM than the source.
• PHP versions: Make sure the destination server offers the PHP versions your sites need (especially for older applications).
• Database engine: Confirm that MySQL/MariaDB versions are compatible, particularly if you use newer features or strict SQL modes.

When we onboard a new customer at dchost.com, this compatibility check is one of the first things we look at during migration planning.

2. Verify disk space and backup location

• On the source server, ensure you have enough free disk space to create the backup archive (it can temporarily be close to the size of your entire account).
• On the destination server, confirm you have enough space to upload and restore the backup, plus headroom for logs and growth.
• If possible, plan to store an extra copy off‑site as part of a 3‑2‑1 backup strategy with at least one off‑site copy.

3. Plan your DNS and email cutover

Most downtime and email issues during migration come from DNS, not from the backup itself. Before you start:

• Identify whether your domain uses nameservers on the cPanel server or an external DNS provider.
• Note your current MX, SPF, DKIM and DMARC records, especially if you use third‑party email or special routing.
• Lower DNS TTLs (e.g. from 3600 to 300) a day or two before migration so that changes propagate quickly when you switch to the new server. For deeper strategies, see our guide on DNS TTL planning for zero‑downtime migrations.

If you are changing hosting company as well as server, our domain and DNS migration checklist when changing hosting provider is a useful complementary reference.

4. Decide how you will restore on the new server

Your restore path depends on your access level on the destination cPanel server:

• You have WHM (root or reseller) access: You can restore the entire account directly from the full backup file. This is the cleanest option.
• You only have normal cPanel access: Your new hosting provider’s support needs to restore the full backup via WHM, or you will use a more manual method.

We will cover both situations in the sections below.

Step‑by‑Step: Taking a Full cPanel Backup on the Source Server

The screenshots may differ slightly between themes (Paper Lantern, Jupiter, etc.), but the menu names are consistent.

1. Log in to cPanel

• Use your cPanel URL (often something like https://yourdomain.com:2083 or a host‑provided link).
• Log in with your cPanel username and password.

2. Open the Backup or Backup Wizard tool

• In the Files section, click Backup.
• If you prefer a guided flow, you can also use Backup Wizard, but the same full backup option appears in both.

3. Generate a full account backup

1. Under Full Backup, click Download a Full Account Backup.
2. On the next screen, choose your Backup Destination:
   • Home Directory – simplest option; the archive will be created under your account.
   • Remote FTP/SCP Server – useful if you want the backup to go directly to another server or backup storage.
3. Enter your email address if you want a notification when the backup completes.
4. Click Generate Backup.

Depending on your account size, this can take anywhere from a few minutes to over an hour. Avoid making big content changes during this period so the snapshot is consistent.

4. Download the backup file

When the backup is finished:

• Return to the Backup page.
• Under Backups Available for Download, you will see a file like backup-10.02.2026_12-30-01_username.tar.gz or cpmove-username.tar.gz.
• Click the file to download it to your computer or copy it via SFTP/SSH to the destination server.

Keep this file safe. Treat it like a copy of your entire digital office: it contains website code, user data and email content. Do not send it over unencrypted channels or leave it in public links.

Method 1: Restoring a Full cPanel Backup via WHM on the New Server

This is the preferred method when you (or your hosting provider) have WHM access on the destination server. At dchost.com, this is how we normally move accounts between our cPanel servers and VPS nodes.

1. Upload the backup to the destination server

You have two common options:

• Upload via WHM interface – WHM can accept the backup file from your browser during restore.
• Upload via SFTP/SSH – place the backup file under /home or /home/cpmove on the destination server so WHM can detect it automatically.

If the filename starts with cpmove-username.tar.gz, WHM will usually recognize it instantly.

2. Open WHM and access the restore tools

1. Log in to WHM on the destination server (for example, https://serverhostname:2087).
2. In the search bar, type Restore.
3. Click Restore a Full Backup/cpmove File (menu names may vary slightly, e.g. “Restore a Full Backup” or “Restore a cPanel Account”).

3. Select the backup and restore options

1. Under Select a cpmove file, choose your uploaded file from the list.
2. Check the restore options:
   • Overwrite – only use if you are replacing an existing account on the destination server with the same username.
   • IP assignment – decide if the account should use a shared IP or dedicated IP.
   • Package – you can restore with the original package or map it to a local package.
3. Click Restore and wait for the process to complete.

The log output will show each step: creating the user, restoring files and databases, recreating email accounts, DNS zones, SSL, and cron jobs. Read through it for warnings or errors.

4. Verify the restored cPanel account

Before you switch DNS, log in to the restored cPanel account and check:

• File Manager – confirm public_html and addon domains’ document roots are present.
• MySQL Databases – ensure all databases are listed and associated users exist.
• Email Accounts – verify accounts and mailbox sizes look correct.
• SSL/TLS Status – confirm certificates were restored or plan to reissue with AutoSSL.
• Cron Jobs – check scheduled tasks were imported correctly.

5. Test the websites using a preview method

You want to test the new server without changing public DNS yet. Common options:

• Temporary hostname URL: Many cPanel servers support preview via a URL like https://serverhostname/~username (not ideal, but quick for basic checks).
• Hosts file override on your PC: Add an entry mapping your domain to the new server’s IP so only your machine sees the site from the new server.

Browse key pages, login forms, cart/checkout (for shops) and any custom applications. Look for PHP errors, broken images or missing uploads.

6. Switch DNS to point to the new server

Once tests are clean:

• If your domain uses nameservers provided by the old cPanel server, update the domain to use the new nameservers from your new hosting.
• If your domain uses an external DNS provider (e.g. a registrar or DNS service), update the A and AAAA records to point to the new server’s IP, and verify MX/SPF/DKIM/DMARC if email has moved too.

This is where prior TTL planning pays off: with a low TTL, most visitors will switch to the new server within a few minutes. If you want to treat this like a resilience test, our article on running a disaster recovery drill for cPanel and VPS restores covers how to structure tests and rollbacks.

Method 2: Full Backup Restore When You Only Have cPanel (No WHM)

If you do not manage the server and only have standard cPanel access on the destination, you cannot run the WHM restore yourself. But you still should take a full backup from the old server – it is the cleanest package for your hosting provider to restore.

1. Generate and download the full backup on the old server

Follow the earlier steps to create a full backup via the Backup tool and download the .tar.gz archive.

2. Open a support ticket with your new hosting provider

Most providers that use cPanel/WHM can restore a full backup for you. Typically they will ask for one of these:

• A download URL to the backup file (for example, uploaded to your own object storage or a password‑protected link).
• Or temporary access (SFTP/FTP) to upload the backup into your new account so they can move it into the right location on the server.

At dchost.com, we regularly restore customers’ full cPanel backups when they move to our shared hosting, VPS or dedicated servers. The process is essentially the same WHM restore described above, just executed by our operations team instead of the customer.

3. Coordinate the DNS cutover time

Ask your new provider to let you know when the restore is complete so you can:

• Test the site with a preview URL or hosts file override.
• Plan a DNS cutover window (often during lower‑traffic hours).
• Announce a brief maintenance window if your application is very write‑heavy (e.g. busy e‑commerce or forums) so you are not writing to the old server while DNS is changing.

Once everything checks out, update your domain’s nameservers or A records as needed.

Method 3: Manually Restoring from a Full Backup Archive (Advanced)

Sometimes a WHM restore is not possible: perhaps the destination server uses cPanel but the provider refuses full restores, or you are moving some parts of the account only. In that case, you can treat the full backup as a regular tar.gz archive and restore key components manually.

Warning: This method is more error‑prone and requires comfort with file structures and databases. Whenever possible, prefer a proper WHM full account restore.

1. Extract the archive locally

On your computer or a temporary VPS, extract the backup:

tar -xzf backup-10.02.2026_12-30-01_username.tar.gz

You will see folders like homedir, mysql, etc, mail and some metadata files.

2. Restore website files via cPanel File Manager or SFTP

• Inside the extracted homedir, locate public_html and any addon domain folders.
• Upload these to the destination account’s home directory (usually replacing the existing empty public_html or site folder).
• Preserve folder structure and hidden files like .htaccess.

3. Restore MySQL databases manually

In the backup, database dumps often live under mysql/ or mysql.sql files. On the destination cPanel account:

1. In cPanel, open MySQL Databases and recreate each database with the same name if possible.
2. Create database users and assign them to the databases with ALL PRIVILEGES.
3. Use phpMyAdmin or the MySQL command line to import each .sql dump into the corresponding database.
4. Update any configuration files (for example, wp-config.php for WordPress or .env files for Laravel) if database names, users or passwords have changed.

4. Restore email accounts and messages

Email is the trickiest part to restore manually, because cPanel organizes mail in a specific directory structure and uses configuration files in etc/ as well as mailboxes under mail/.

1. First, in the destination cPanel, recreate each email account via the Email Accounts interface (same addresses and domains).
2. From your extracted backup, copy the contents of mail/domain.com/user/ into the corresponding path on the new server (you will typically need SFTP + shell access for this level of control).
3. Make sure file and folder ownership/permissions match those of newly created mailboxes.

If you do not have shell access or are not comfortable with maildir structures, a better alternative is often to sync mailboxes over IMAP (for example, using IMAP sync tools) from the old server to the new cPanel, then handle web and database content via backup.

DNS, Email and SSL: Final Checks After Restoring the cPanel Backup

Once your backup is restored and files/databases look correct, it is time to make sure your visitors and email flow reach the new server cleanly.

1. Confirm DNS zones on the new server

• In WHM or cPanel’s Zone Editor, confirm that A, AAAA, CNAME and MX records reference the new server IPs.
• Ensure any custom DNS records you previously created (for APIs, subdomains, verification TXT records) are present.
• If you use external DNS, replicate the relevant records there instead of relying on the restored zone file.

2. Re‑establish email authentication: SPF, DKIM, DMARC

If your email is hosted on the new cPanel server, review:

• SPF – update the allowed sending IPs/hosts to match the new server.
• DKIM – in cPanel, re‑enable DKIM or copy the TXT record to your external DNS if needed.
• DMARC – ensure DMARC records reflect your policy and reporting addresses.

Our in‑depth article on SPF, DKIM and DMARC for cPanel and VPS email walks through these records step‑by‑step if you want to harden deliverability after the move.

3. Check and renew SSL certificates

Depending on how certificates were originally issued:

• If you used AutoSSL/Let’s Encrypt via cPanel, the restored certificates may work, but it is often cleaner to trigger AutoSSL on the new server to issue fresh certificates.
• If you installed commercial SSL certificates, make sure the private keys and CA bundles restored correctly or re‑install them.

For a practical walkthrough on automatic free certificates in cPanel, see our guide on setting up Let’s Encrypt SSL on cPanel with automatic renewals.

4. Run functional tests after DNS changes

Give DNS some time to propagate according to your TTL settings, then:

• Visit the site from different networks (desktop, mobile data, VPN) to ensure you hit the new server.
• Test key user journeys: logins, forms, search, checkout, account pages, file uploads.
• Send and receive test emails from internal addresses and from external providers to confirm SMTP and IMAP/POP are working correctly.
• Check error logs in cPanel (Errors, Raw Access Logs, etc.) for fresh warnings after the move.

Treat Every Restore as a Small Disaster Recovery Drill

A cPanel‑to‑cPanel migration is not just about moving today’s data; it is also a chance to prove that your backups are truly restorable. Many teams discover backup issues only when something breaks. By approaching a planned migration like a small disaster recovery exercise, you get confidence that, if you ever need to restore in an emergency, the process is familiar and tested.

We recommend documenting your steps as you go:

• Where you stored the backup file (local, off‑site, object storage, another VPS).
• Exactly how long the backup and restore steps took.
• Any surprises: missing DNS records, email issues, or application configuration changes required.
• What you would adjust next time to reduce risk or downtime.

If you want to go deeper into running proper, repeatable restore tests, our article on disaster recovery drills for hosting environments covers how we design and execute these tests on cPanel and VPS servers.

Conclusion: Moving cPanel Accounts Safely, Not Just Quickly

Moving a cPanel account to another server does not have to be risky or complicated. With a proper full cPanel backup, a compatible destination server and a bit of planning around DNS and email, the whole process becomes predictable. The safest path is almost always a WHM full‑account restore from the cpmove backup file, followed by careful verification and a controlled DNS switchover. Where WHM access is not available, working with your hosting provider’s support or, as a last resort, manually restoring files and databases can still get you there – as long as you treat the backup archive with care.

At dchost.com, we use these same principles when migrating customers between our shared hosting, VPS, dedicated and colocation servers: full backups, restore tests, DNS planning and clear rollback options. Once your move is complete, take the opportunity to strengthen your backup routine, ideally with multiple copies and off‑site storage as described in our 3‑2‑1 backup strategy guide. That way, the next time you need to restore – whether for a clean migration or an unexpected incident – you will already have a proven, well‑documented process that keeps your sites, emails and data safe.