Moving Hosting Without Drama: The Migration Checklist

Moving hosting is usually done for valid reasons: the website is becoming slow, costs are rising, technical support is disappointing, or the old server no longer meets the application's needs. The problem is that migration is not just about re-uploading the public_html folder and pointing the domain to a new address.

What needs to be involved can include databases, email, cron jobs, DNS, SSL certificates, PHP versions, firewall configurations, and even transaction data that comes in during the migration process. Forgetting one part can make the website appear normal, but forms may not send emails, payments may fail, or new messages may still go to the old server.

Here’s a practical checklist for moving your website with reduced risk, whether you are using cPanel, WHM, VPS, or assistance from a hosting provider.

1. Map out the website content before moving anything

Start by creating a list of assets that are actually in use. Don’t just note the main domain. Also check subdomains, addon domains, email, databases, and external services.

Main domain and subdomains, such as www, app, or mail.
Website folders and document roots for each domain.
Databases and their connection credentials.
Email accounts and forwarder addresses.
DNS records such as A, CNAME, MX, TXT, and DKIM.
Cron jobs, scheduled tasks, webhooks, and API integrations.
SSL certificates or AutoSSL configurations.
PHP versions, extensions, and server configurations required by the application.

This step may sound administrative, but it often makes the difference between a smooth migration and one full of surprises. Many websites may look simple from the outside, but they might have one subdomain for an application, one email server, and several DNS records managed in different places.

2. Prepare a recoverable backup

A backup is not considered ready just because a ZIP file was successfully created. A useful backup is one that has been tested for recovery.

Store at least three components separately: website files, database dumps, and copies of DNS records. If using cPanel, the Backup Wizard feature can be used to create a backup of the entire account or specific parts of the website. However, the availability of features and storage locations still depends on the provider's configuration.

For MySQL databases, create an export using the appropriate format and note the resulting file size. After transferring, compare the number of tables or the size of the database on the new server. Small differences may not be a problem, but large discrepancies need to be checked before changing the DNS.

Rule of thumb: do not close the old hosting until the website on the new server has been tested and you have the latest backup from the old server.

3. Lower the DNS TTL before the migration day

TTL or Time to Live is the duration a DNS record is stored by a resolver before being checked again. A lower TTL can help the new IP address propagate faster, although it does not eliminate the entire propagation process.

cPanel documentation suggests lowering the DNS TTL a few days before migration, and in its migration guide, it recommends a temporary value of 300 seconds to help reduce downtime. After the process stabilizes, the TTL should be returned to a more reasonable value so that resolvers do not query the record too frequently. ([docs.cpanel.net](https://docs.cpanel.net/knowledge-base/transfers-and-restores/how-to-manually-migrate-accounts-to-cpanel-from-unsupported-control-panels/?utm_source=openai))

It is important to note that changing the TTL just a few minutes before the move is not always effective. Resolvers may still retain the old value from the previous period.

4. Match the server environment before transfer

Applications running on the old server may not necessarily work directly on the new server. Check the PHP version, MariaDB or MySQL, PHP extensions, web server, upload limits, execution time limits, and rewrite rules.

For migrations between cPanel servers, official documentation recommends making the software environment as similar as possible. Differences in database versions or web server components can cause errors after the account is moved. Therefore, major updates should be done after the basic migration is successful, not simultaneously with the server move. ([docs.cpanel.net](https://docs.cpanel.net/knowledge-base/transfers-and-restores/how-to-move-all-cpanel-accounts-from-one-server-to-another/?utm_source=openai))

If using WordPress, also pay attention to the PHP version, permalink configuration, upload folder, and plugins that store absolute paths. For custom applications, keep a separate list of environment variables and API secrets. Do not copy configuration files carelessly if they contain database passwords or private keys.

5. Move the website, email, and DNS as three separate tasks

Websites and emails often use the same domain, but their technical paths are different. Websites typically rely on A records or CNAME, while emails depend on MX, SPF, DKIM, and sometimes DMARC.

If you are moving the website but the email is still managed by Google Workspace, Microsoft 365, or another provider, do not delete the old MX records. Conversely, if the email is also being moved to the new hosting, ensure that the mailbox and old messages are copied before directing the MX to the new server.

In the WHM Transfer Tool, DNS settings determine whether the DNS zone is created or updated on the destination server. If the DNS update option is turned off, the zone and email routing may need to be created manually. cPanel also warns that shutting down the old server too quickly can cause custom records like TXT or MX to be lost if they are only stored on the old server. ([docs.cpanel.net](https://docs.cpanel.net/whm/transfers/transfer-tool/?utm_source=openai))

6. Test the new server before changing DNS

Do not use DNS changes as a testing method. Test the website directly on the new server first.

Some options you can use:

Use a temporary URL if the application supports it.
Edit the hosts file on your computer to point the domain to the new server's IP.
Use a staging subdomain to test the application where possible.
Check the website with a browser, curl, and HTTP status monitoring tools.

Check the login page, contact forms, search functionality, file uploads, payments, admin dashboard, images, outgoing emails, and scheduled processes. For websites with transactions, enable a short maintenance mode or temporarily halt data changes during the final synchronization.

7. Change DNS, but do not immediately shut down the old server

Once the new server passes testing, change the A record or nameserver as planned. Check the results from multiple networks as different resolvers may see changes at different times.

cPanel documentation suggests testing the website before changing the DNS, then making the DNS changes as soon as possible after the transfer and verification are complete. While the DNS has not fully transitioned, some visitors may still access the old server. ([docs.cpanel.net](https://docs.cpanel.net/knowledge-base/technical-support-services/cpanel-migration-services-and-guides/?utm_source=openai))

Keep the old hosting active during the observation period. The exact duration depends on the TTL, type of DNS, and how often the website receives data changes. For online stores, important forms, or applications with logins, monitor logs and databases on both servers to ensure no data is left behind.

8. Post-migration checklist

Ensure the main domain and all subdomains point to the correct IP.
Test HTTPS without certificate warnings.
Check HTTP to HTTPS redirects and www or non-www rules.
Test incoming emails, outgoing emails, and messages to external addresses.
Check cron jobs, webhooks, automated backups, and monitoring.
Review error logs during the first few hours.
Restore the DNS TTL after conditions stabilize.
Keep records of IPs, credentials, migration dates, and configuration changes.

What does this mean for us?

Safe hosting migration is more like an operational transfer than just copying files. The key is to know what is being moved, test the new environment, keep the old server available, and set the DNS at the right time.

If you do not have root access or are not familiar with DNS and databases, take advantage of migration services from your hosting provider. cPanel itself differentiates the transfer process based on access rights and provides different paths for regular account owners and server administrators. ([docs.cpanel.net](https://docs.cpanel.net/knowledge-base/transfers-and-restores/how-to-move-all-cpanel-accounts-from-one-server-to-another/?utm_source=openai))

With this checklist, moving hosting does not have to be a moment when the website suddenly disappears. You can still make significant changes, but with a clear recovery path if something does not go as planned.

Sources & further reading

– Rio Yotto @rioyotto