How to migrate a website to a new host

The short version

To migrate a website to a new host, you back up everything at the old host, recreate the site on the new host, test it privately, then point the domain at the new server. The order matters more than the tools. Most failed migrations skip testing or cancel the old host too early.

Here is the sequence this guide follows:

1. Plan and take inventory.
2. Lower your DNS TTL.
3. Take a full backup.
4. Move files and databases.
5. Test using your computer's hosts file.
6. Move or reconnect email.
7. Switch DNS.
8. Check, then cancel the old host.

Step 1: Plan and take an inventory

Write down everything the site depends on before you touch it. A simple spreadsheet works.

• Websites and subdomains: yourbusiness.in, www, shop.yourbusiness.in, staging sites.
• Databases: names, users and which site uses which.
• Email accounts: every mailbox, forwarder and autoresponder. Count them, because a smaller plan may not hold them all.
• DNS records: export or screenshot the full zone, including TXT records for Google Search Console, your payment gateway or other services you verified.
• Scheduled tasks: cron jobs for backups, invoice emails or sitemap updates.
• Software versions: PHP version and any PHP extensions the site needs.

ODHOST note: Shared plans differ in websites, databases and mailboxes. Spark allows 1 website and 5 email accounts; Boost 3 and 25; Thrive 5 and 40; Turbo 10 and 80; Elite is unlimited. Match your inventory to a plan before ordering, or use the hosting plan finder.

Pick a quiet time to switch. For a shop in India that is often late night or early morning IST, and never during a sale.

Step 2: Lower the DNS TTL a day early

TTL (time to live) tells resolvers how long to cache a DNS record. If your A record has a TTL of 86400 seconds, some visitors can keep reaching the old server for a full day after you switch.

Change the TTL of your A, AAAA, www and MX records to 300 seconds at least 24 hours before the move. When you later switch, most visitors follow within about five minutes.

Step 3: Take a full backup

Back up at the old host even if you plan to use a migration plugin. This is your safety net.

On cPanel, the Backup tool can generate a full account backup or let you download a home directory backup and individual database backups. The Backup Wizard walks through the same choices. Download the files to your computer; do not leave the only copy on the server you are leaving.

On any host, the minimum is:

• An archive of the website folder (often public_html).
• An SQL export of every database, from phpMyAdmin or the command line.
• A copy of any email you cannot afford to lose.

Developers with SSH access at the old host can export the database and files like this:

mysqldump -u dbuser -p dbname > dbname-2026-10-13.sql
tar -czf site-files.tar.gz public_html/

Step 4: Move the files and database

cPanel to cPanel

If both hosts use cPanel, a full account backup can often be restored at the new host in one go. Restoring a full cPanel backup usually needs the host's administrator to do it, so ask the new host's support whether they can restore it for you.

If you do it yourself instead:

1. Upload the site archive to the new account with File Manager or FTP and extract it in the correct folder. See uploading files with File Manager or FTP.
2. Create a new database and user in cPanel, and give the user all privileges on that database. The MySQL database help article shows each screen.
3. Import the SQL file into the new database using phpMyAdmin.
4. Update the site's configuration file with the new database name, user and password.

WordPress

You have two reasonable options.

With a migration plugin. Several WordPress plugins package the files and database into one archive that you import on a fresh WordPress install at the new host. They are convenient for small and medium sites. Watch the archive size: free versions of some plugins cap the import size, and shared hosting upload limits can block large archives.

Manually. Copy the files and database as in the cPanel steps above, then edit wp-config.php:

define( 'DB_NAME', 'newcpaneluser_wp' );
define( 'DB_USER', 'newcpaneluser_wpuser' );
define( 'DB_PASSWORD', 'use-the-new-strong-password' );
define( 'DB_HOST', 'localhost' );

On cPanel, database names and users usually carry the account username as a prefix, so the old names will not match exactly. If the domain is not changing, you do not need to search and replace URLs in the database. If the domain is changing, follow the WordPress guide to moving a site, because serialised data breaks with a plain text replace.

Step 5: Test before anyone else sees it

Your hosts file lets your own computer reach the new server while the rest of the world still goes to the old one. This is the most important step in the whole migration.

The file is at C:\Windows\System32\drivers\etc\hosts on Windows (open Notepad as Administrator to edit it) and /etc/hosts on macOS and Linux (edit with sudo). Add a line with the new server's IP address, from your welcome email or client area, and your domain:

203.0.113.10  yourbusiness.in  www.yourbusiness.in

Then open the site in a private browser window and check:

• Home page, menus and several inner pages load.
• Images, CSS and JavaScript load (no broken layout).
• Contact forms send, and you receive the email.
• Login, cart and checkout work, including a test payment in your payment gateway's test mode if you run a shop.
• No database connection errors. If you see one, the database connection fix lists the usual causes.

Remove the hosts file line when you finish testing, or you will keep seeing the new server and miss real problems later.

Step 6: Plan the email move carefully

Email causes more migration trouble than websites, because mail keeps arriving during the switch.

• If email stays where it is (for example Google Workspace or Microsoft 365), you only move the website. Keep the MX, SPF, DKIM and DMARC records exactly as they are in the new DNS zone.
• If email moves to the new host, create every mailbox on the new host with the same address first. Then copy old messages. Mail clients set up with IMAP can drag folders from the old account to the new one; some control panels also offer a migration or import tool.
• Update SPF. If the new host sends your mail, its servers must appear in your SPF record. The guide to SPF, DKIM and DMARC shows how.

For a day or two, some mail may still land on the old server. Check the old mailboxes through webmail before you cancel.

Step 7: Switch DNS

Freeze changes on the old site (no new posts, orders paused or a maintenance notice), take a final database export if anything changed since Step 4, import it, then switch.

You can change the nameservers to the new host's, or keep your DNS provider and change the A record. Both methods are explained in how to connect a domain to hosting. Because you lowered the TTL, most traffic moves quickly. The DNS propagation help article explains why a few users lag behind.

Step 8: Check, then cancel the old host

Over the next few days:

1. Confirm the SSL certificate is active on the new server and the site loads over HTTPS.
2. Check error logs and Google Search Console for crawl errors.
3. Recreate cron jobs and confirm scheduled emails go out.
4. Raise the TTL back to 3600 seconds or more.
5. Take a fresh backup on the new host. Keep your own copy as well; the cPanel backup restore article explains how backups are used.
6. Cancel the old hosting only after a week without problems.

Migration checklist

Done	Task
☐	Inventory of sites, databases, mailboxes, DNS records, cron jobs
☐	TTL lowered to 300 seconds 24 hours ahead
☐	Full backup downloaded to your computer
☐	Files uploaded and database imported on the new host
☐	Config file updated with new database details
☐	Site tested through the hosts file
☐	Mailboxes created and old mail copied
☐	SPF updated if the sending server changed
☐	DNS switched and verified
☐	SSL active, HTTPS forced
☐	Old host kept for at least a week

Getting help

If you would rather not do this yourself, ask ODHOST support whether migration help is available for your plan before ordering. You can reach the team through the contact page or a ticket in the client area. A developer or agency can also run the process above for you; give them this checklist so you can confirm each step.