Zero-downtime website migration guide: cPanel to cPanel, step by step

Almost all of the downtime experienced during a website migration comes from a single cause: the wrong order of operations. If DNS is changed before the files are transferred, visitors land on an empty server; if you switch over without lowering the TTL, the old address stays in cache for hours. When you get the order right, your visitors will not even notice that you moved.

In this guide we walk through the most common scenario step by step — migrating from cPanel to cPanel: taking a backup, lowering the DNS TTL, transferring, testing before going live, and post-migration checks.

Before the migration: inventory and timing

The first job is to list everything that needs to move. Most problems come from gaps along the lines of “I moved the files but forgot the email accounts.” Your checklist should include at least the following:

• Web files (public_html and any additional directories)
• Databases and connection details
• Email accounts, forwarders, autoresponders
• Cron jobs, SSL certificates, subdomains
• Existing DNS records — take a screenshot of your A, MX, TXT and CNAME records

Schedule the switchover for the hour when traffic is lowest; for most sites that is after midnight. The most critical rule is this: never cancel your old hosting account until the migration has fully settled. Running both accounts in parallel for a while is your insurance policy.

Also verify now that the PHP and MySQL versions on the destination side are compatible with your site. For example, on SunucuCenter’s Linux hosting plans you can select the PHP version through cPanel, so you will not run into a version incompatibility when migrating older software.

Step 1: Take a complete backup

In cPanel, follow the Backup > Download a Full Backup path. The resulting backup-date_username.tar.gz file contains the entire account: files, databases, email accounts, forwarders and cron jobs. If you have SSH access, you can do the same thing from the command line:

# For the files
tar -czvf site-backup.tar.gz public_html/

# For the database
mysqldump -u username -p database_name > backup.sql

Do not leave the backup on the server only. If something goes wrong during the migration, the copy you can fall back on is the one you downloaded to your own computer. On large sites, account for the size of the backup file and the download time in advance.

Step 2: Lower the DNS TTL value

TTL (Time to Live) determines how long a DNS record is held in cache on servers across the internet. In most panels the default value is 14400 seconds, that is 4 hours. If you change the IP without lowering this value, some visitors will keep seeing the old server for 4 hours.

24 to 48 hours before the switchover, reduce the TTL of the A record to 300 seconds (5 minutes). To see the current value:

dig +noall +answer yoursite.com
# yoursite.com.  14400  IN  A  203.0.113.10

The number in the middle is the TTL in seconds. You have to make the change wherever you manage your DNS records: your domain registrar’s panel, your hosting cPanel or your external DNS service. Once the migration is complete, remember to raise the TTL back to its previous value; a permanently low TTL increases DNS query load unnecessarily.

Which migration method suits you?

Scenario	Recommended method	Difficulty
Small/medium site, cPanel on both sides	Full backup + restore	Easy
Only FTP access on the source side	Manual file and database transfer	Moderate
Large site (over 10 GB), many email accounts	Transfer over SSH/rsync	Advanced
I do not want to deal with technical steps	Migration support from the new provider	—

The last row is not an option to underestimate: cPanel-to-cPanel migrations are a routine operation on the provider side. At SunucuCenter you can run this process together with the 24/7 support team and leave the steps that require elevated privileges, such as the restore, to the team.

Step 3: cPanel to cPanel transfer

Migrating with a full backup

Upload the full backup file you downloaded to the new server. Because restoring a full backup requires WHM (root) privileges, ask your new provider’s support team to create the account from that backup. The advantage of this method is that everything, from email accounts to cron jobs, arrives in one go and with the same settings.

Manual migration

If you cannot use a full backup, the order is as follows: archive the files, upload them to the File Manager in the new cPanel and extract them there; export the database from phpMyAdmin and import it into the empty database you created on the new server. Because the database name and user will most likely change on the new side, you need to update your site’s configuration file:

# In wp-config.php for WordPress
define('DB_NAME', 'newaccount_db');
define('DB_USER', 'newaccount_user');
define('DB_PASSWORD', 'new_password');

Recreate the email accounts in the new cPanel with the same addresses. Do not skip copying the cron jobs from the old panel and defining them in the new one; scheduled backups and automated jobs are the most frequently forgotten piece.

Step 4: Test without changing DNS

The most valuable trick in a migration is the hosts file. If you write the new server’s IP into your computer’s hosts file, you can view the site on the new server without touching DNS:

# Windows: C:WindowsSystem32driversetchosts
# macOS / Linux: /etc/hosts
203.0.113.10  yoursite.com www.yoursite.com

This line affects only your own computer; visitors keep seeing the old server. In this state, test the home page and inner pages, the admin panel login, the contact form, image loading and, if you have one, the payment step. You resolve the problems while everyone still sees the old site, that is, with no pressure. When testing is finished, remember to delete the hosts line.

Step 5: Update DNS and complete the switchover

If the tests are clean, point the A record to the new server’s IP or change the name servers to those of your new provider. If you lowered the TTL to 300, the majority of visitors will flow to the new server within minutes.

Do not shut down the old server right away; keep both live for 24 to 48 hours. A small number of visitors whose DNS cache has not refreshed yet will be served from the old server during this period. If you use email, check the mailboxes on both servers until the MX record has propagated; messages sent in the meantime may have landed on the old server.

Post-migration final checks

• SSL: Verify that the certificate is installed and valid on the new server; in cPanel, AutoSSL usually issues the certificate automatically shortly after the DNS switchover.
• Email: Send and receive a test message; update the SPF and DKIM records for the new server.
• Cron jobs and forms: Verify that scheduled jobs are running and that form submissions are being delivered.
• TTL: Raise the value you lowered to 300 back to the 3600-14400 range.
• Old account: Cancel it after 1 to 2 weeks without problems; take one final backup beforehand.

If your reason for moving is that shared hosting is no longer enough, the same steps apply when you move up a tier: migrating to a VDS server whose resources belong entirely to you also follows the full backup + restore logic, and SunucuCenter’s VDS plans with NVMe SSD infrastructure start at 44.99 TL/month.

Frequently asked questions

Will my site be down during the migration?

Not if you follow the right order. While the old server is live, a copy is prepared and tested on the new server; when DNS changes, visitors are directed to the new server without interruption. Downtime only occurs if you cancel the old account too early or switch over without lowering the TTL.

How do I prevent data loss on a site that is updated constantly (an e-commerce site, for example)?

Files generally do not change; what matters is the most recent order, membership and comment data. Transfer the current state of the database once more right before the DNS change; on busy sites, putting the site into maintenance mode for a few minutes during this final transfer is the safest approach.

Do I have to move my domain to the new company as well?

No. Domain and hosting are independent services; pointing the DNS records to the new server is enough. If you want to consolidate management in one place, you can carry out the domain transfer as a separate step after the site migration has fully settled.