Website Migration Checklist: How to Move Your Website to a New Host

Moving a website to a new host without downtime comes down to order: copy everything to the new server while the old one keeps serving visitors, test the new copy privately, then switch DNS with a low TTL and keep the old hosting active for a few more days. When migrations go wrong, it is rarely the website files. It is the forgotten pieces: email, cron jobs, SSL and DNS records nobody wrote down.

Use this checklist in four stages: before, during, the switch, and after.

Before the move: inventory everything

Write down what you have before you touch anything. A migration fails on the item that was not on the list.

• Domains and subdomains: the main domain, www, and any shop., blog. or app. subdomains, plus addon or parked domains.

• Sites and software: CMS and version (WordPress, Joomla, a custom PHP app), PHP version and any special extensions or settings.

• Databases: names, sizes, and which site uses which.

• Email: every mailbox, forwarder and alias, and where the MX records point today. Mail hosted elsewhere (for example Google Workspace) must keep its records untouched.

• DNS zone: export or screenshot every record: A, CNAME, MX, TXT (SPF, DKIM, verification codes), SRV.

• Scheduled tasks: cron jobs in cPanel or crontab. They are invisible until a report stops arriving.

• Integrations: payment gateway webhooks, SMTP credentials, and APIs that allow-list your server IP. These break silently when the IP changes.

Then find out who serves your DNS today. It could be the registrar, the old host or Cloudflare, and it decides where you will make the switch:

dig NS example.com +short

Replace example.com with your domain. Three more preparation steps:

1. Lower the TTL 24 to 48 hours ahead. Set the A record (and www) TTL to 300 seconds. Resolvers keep the old value until the old TTL expires, so if it was 86400 (one day), you must lower it at least a day before the switch.

2. Take a fresh full backup of files, databases and email, and store it outside both hosts. Our WordPress backup and restore guide shows exactly what to include.

3. Collect access: old control panel, registrar account, DNS panel, SSH or FTP, and CMS admin. Do not cancel the old hosting yet. Check its renewal date and plan at least a week of overlap.

During the move: copy, then test privately

Copy files and databases

Between two cPanel servers, the cleanest path is a full account backup restored on the new server, because it carries files, databases, email and settings together. Otherwise, copy the files over SSH or SFTP, export each database, import it on the new server, and create the database user with the same permissions.

After importing, update the connection details in the app's config file: wp-config.php for WordPress, configuration.php for Joomla, or the .env file for most frameworks. Match the PHP version to what the site ran before; jumping several versions during a move mixes two problems into one.

Recreate email

Create the same mailboxes on the new host, then copy old messages over IMAP. Mail that arrives during the DNS switch can land on either server for a few hours, so plan one final sync after the switch. Email is where most migrations lose data; we cover the details in our guide to zero-downtime DNS and email migration.

Test with the hosts file

You can see the site on the new server before changing public DNS. Add a line to your computer's hosts file that points your domain at the new server IP. The IP below is a documentation example; use your new server's address:

203.0.113.10  example.com  www.example.com

On Windows the file is C:\Windows\System32\drivers\etc\hosts (open Notepad as administrator). On macOS and Linux it is /etc/hosts. Flush the DNS cache afterwards: ipconfig /flushdns on Windows, or this on macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

From a terminal you can test without editing any file:

curl -I --resolve example.com:443:203.0.113.10 https://example.com

If the new server has no certificate yet, curl reports a certificate error. That is expected before the switch; add -k for this test only.

Now click through what matters: homepage, inner pages, login, contact forms, search, checkout, image galleries and the admin panel. Remove the hosts line when you finish, or you will keep seeing the new server and miss problems your visitors see.

Freeze or resync dynamic content

A store or forum keeps writing to the old database while you test. Either schedule a short content freeze and do a final database export right before the switch, or accept a final resync step. Orders placed on the old server after your copy are otherwise lost.

The switch: point DNS to the new server

You have two options. Change the nameservers to the new host so it serves the whole DNS zone, or keep DNS where it is and edit only the A and CNAME records. Our guide on how to connect a domain to hosting explains when each method fits.

If you change nameservers, recreate every record from your inventory in the new zone first, especially MX, SPF, DKIM and verification TXT records. A missing MX record is the most common cause of "email stopped working after we moved".

With a 300-second TTL, most visitors reach the new server within minutes to an hour. Nameserver changes go through the domain registry and can take up to 24 to 48 hours to settle everywhere, as a rule of thumb. Check what public resolvers see:

dig +short example.com A
dig @8.8.8.8 +short example.com A
dig @1.1.1.1 +short example.com A

After the switch: the 48-hour checklist

• SSL: a valid certificate for both example.com and www, HTTPS forced, and no mixed-content warnings.

• Email: send and receive a test from every important mailbox. If the site sends mail from the new server, update SPF to include it and publish the new DKIM key.

• Forms and transactional mail: submit each contact form and place a test order.

• Cron jobs: recreated and running at the right times.

• Integrations: payment webhooks receive events, IP allow-lists include the new address.

• Redirects: old redirects still return 301, not 404.

• TTL: raise it back to 3600 or more once everything is stable.

• Old hosting: keep it for about a week, check no new mail is landing there, take a last backup, then cancel.

Keeping SEO safe during a migration

A host change with the same domain and the same URLs does not need any change of address in Google. What protects your rankings:

• Do not change URLs at the same time. A redesign or a new permalink structure is a separate project. If URLs must change, map every old URL to its new one with a 301 redirect.

• Check indexing settings. A copy built as staging often has "Discourage search engines" ticked in WordPress, or a robots.txt that blocks everything. Carried to production, it quietly removes you from search.

• Watch Search Console for a week: crawl errors, a rise in 5xx responses, and page indexing reports. Resubmit the sitemap.

• Keep downtime short. A few minutes of switching does not affect rankings. Days of errors do.

Moving from shared hosting to a VPS adds steps such as installing the web server, PHP and database yourself. That path has its own guide: moving your website to a VPS with zero downtime.

What IM HOST's free migration covers, and what you prepare

If you are moving to IM HOST, you do not have to run this checklist alone. The free website migration service is available to all IM HOST customers and covers files, databases (MySQL, MariaDB and PostgreSQL), email accounts, DNS settings, SSL reinstallation, and CMS sites with their plugins (WordPress, Joomla, Drupal). It works in three steps: you fill in the migration form, the team migrates using the access you share, then they test before the DNS switch.

What helps on your side:

• Login to the old control panel, or a full cPanel backup if you prefer not to share it.

• Access to your registrar or DNS panel, or someone available to change records.

• Your list of mailboxes and anything unusual: cron jobs, custom PHP settings, external services tied to your IP.

• A quiet time window for the switch, such as late evening for a business site.

After the move, change the passwords you shared. For most business sites the destination is shared hosting with cPanel, which includes free daily backups, free SSL and email accounts.

Frequently asked questions

Will my website go down when I change hosting?

Not if you follow the order above. The old server keeps serving visitors while the new one is prepared and tested, and with a low TTL the switch takes minutes. The risk is with dynamic sites, where data written to the old server after your copy needs a final sync.

How long does website migration take?

Copying a typical small business site takes minutes to a few hours, depending mostly on file size and email volume. DNS then needs time to update: minutes with a lowered TTL, up to 24 to 48 hours for nameserver changes.

Will I lose emails during the migration?

You should not, if MX records are recreated before the switch and you run one final mailbox sync afterwards. Messages that arrive during propagation can land on either server, which is why you keep the old hosting active for a few days.

Should I cancel my old hosting before or after migrating?

After. Keep it for about a week after the switch, confirm that nothing new arrives there, take a final backup, then cancel.

Planning a move? Send us the details through the IM HOST free migration service and the team will copy, test and switch your site with you. It is free, and support engineers are available 24/7 if something on the checklist is unclear.