How to migrate your website to a new host without downtime

Step 1: take inventory of what you're moving

Most migration problems don't come from copying files but from something nobody remembered: an email account, a DNS record or a scheduled task. Before touching anything, log in to your current hosting's cPanel or control panel and write down:

• Files: everything in public_html and in addon domain or subdomain folders.
• Databases: name, user and which site uses each one (in WordPress they appear in wp-config.php).
• Email: mailboxes, aliases, forwarders, filters and how much space each account uses.
• DNS records: export or copy the whole zone, including TXT verification records for Google, Microsoft or other services.
• Cron jobs, PHP version and any special settings in .htaccess.

Don't cancel anything yet. If you're not sure how a DNS zone works, review what DNS is.

Step 2: lower the TTL ahead of time

TTL sets how long other servers cache your DNS answers. If it's set to hours, the final switch will take hours to show up. One or two days before the migration:

1. Open the DNS zone editor where your domain is managed today.
2. Change the TTL of the A records for yourbusiness.com, www and MX to 300 seconds.
3. Wait at least as long as the previous TTL before making the final switch.

Step 3: copy the site to the new hosting

Option A: full cPanel backup

If both hosts run cPanel, this is the cleanest route. In the old cPanel open Backup and generate a full account backup. That file includes files, databases, email and DNS, but it can only be restored from WHM, so your new provider has to do it. Many providers help with migrations, and we can point you in the right direction too: ask us before you start. If you only have cPanel access, the same page lets you download the home directory and each database separately and restore them in the new cPanel.

Option B: manual migration

1. Download the files by compressing public_html in File Manager or over SFTP.
2. Export each database from phpMyAdmin (Export → Quick → SQL) or with mysqldump if you have Terminal access.
3. In the new cPanel create the database and user under MySQL Databases. cPanel prefixes them with your username, so the name changes.
4. Upload and extract the files into the new public_html.
5. Import the SQL file from phpMyAdmin or the Terminal.
6. Update your site's connection settings with the new name, user and password.

mysqldump -u old_user -p old_database > backup.sql
mysql -u account_yourbusiness -p account_yourbusiness_wp < backup.sql

In WordPress, the connection settings live in these lines of wp-config.php:

define( 'DB_NAME', 'account_yourbusiness_wp' );
define( 'DB_USER', 'account_yourbusiness_user' );
define( 'DB_PASSWORD', 'new-password' );
define( 'DB_HOST', 'localhost' );

Step 4: test before changing DNS

This is the step that prevents downtime. With your computer's hosts file you tell only your machine that the domain lives on the new server, while everyone else keeps seeing the old hosting. Add a line with the new server's IP (you'll find it in cPanel or in your welcome email):

203.0.113.25  yourbusiness.com
203.0.113.25  www.yourbusiness.com

• Windows: open Notepad as administrator and edit C:\Windows\System32\drivers\etc\hosts. Then run ipconfig /flushdns.
• macOS: edit the file with the command below and flush the DNS cache.

sudo nano /etc/hosts
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Walk through the whole site: pages, forms, login, cart and admin dashboard. When you're done, remove those lines from the hosts file to go back to normal.

Step 5: migrate email carefully

Email is the most delicate part because it keeps arriving while you work. The order that works best is:

1. Create the same accounts with the same addresses on the new server (if you restored a full backup, they already exist). We explain how in create email in cPanel.
2. Change the MX records along with the rest of the DNS (step 6).
3. Copy the old messages over IMAP: with tools like imapsync, the one your new provider offers or, for a few accounts, by adding both to an email client and dragging the folders across.
4. Run a final sync a couple of days later to bring over whatever reached the old server during propagation.

Finally, update your team's devices with the new mail server details; the guide is in set up email in Outlook and on your phone.

Step 6: switch the DNS

You have two ways to send the domain to the new hosting:

• Change the nameservers at your registrar to the new provider's. The DNS zone is then managed there, so first check it has every record from your inventory.
• Change only the A and MX records in the current zone, pointing them to the new IP. It's faster thanks to the low TTL.

Either way, update SPF with the new server's IP and publish the new DKIM key, because each server generates its own; without it your emails may land in spam. We cover it in SPF, DKIM and DMARC and in how to point your domain to your hosting. Once the domain resolves to the new server, turn on SSL by following install free SSL on cPanel.

Step 7: check everything and keep the old hosting

Keep the old hosting active for at least a week. It works as a fallback if something went wrong and lets you recover emails that arrived late. Meanwhile, go through this list:

Before cancelling the old service, download one last full backup and store it off both servers. We explain why in website backups.

Common migration errors

• “Error establishing a database connection”: the details in wp-config.php don't match the new database. Check the name prefix and that the user has privileges on the database.
• The site redirects to a temporary or the old domain: the database stores the URLs. Replace them with a search-and-replace tool.
• Some people see the new site and others the old one: that's DNS propagation. With a low TTL it clears in minutes; with a high TTL it can take up to a day.
• 500 errors after the move: usually an .htaccess directive or a different PHP version. Adjust the version in cPanel and check the error log.
• Sent emails land in spam: SPF wasn't updated or the new server's DKIM wasn't published.