Website Migration Checklist: 20 Things to Check Before You Switch Web Hosts

Most website migrations don’t fail because the files were copied wrong. They fail because of one small thing nobody checked — an email account that existed on the old server and not the new one, a cron job nobody knew about, a DNS record with a 48-hour TTL, or an SSL certificate that was never reinstalled.

This is the checklist we work through before moving any site. Print it, tick it off, and a migration becomes a routine job instead of a nervous weekend. If you want the full walkthrough of the move itself, read how to migrate your website to a new host without downtime — this page is the preparation that comes first.

Why a checklist matters more than the copy itself

Copying files and a database is the easy part. Modern control panels will do it in a few clicks. What catches people out is everything around the website: mail, DNS, certificates, scheduled tasks, third-party services that were whitelisted to the old server’s IP address.

Those items are invisible when the site is working. They only announce themselves after the switch, usually as “our email stopped” or “the payment gateway is rejecting us”. A checklist turns invisible dependencies into a written list before you touch anything.

Part 1 — Before you buy the new hosting

1. Write down what you actually need

Check your current disk usage, database size, monthly bandwidth and PHP version. Buying a plan smaller than your current usage is a common and avoidable mistake. Your existing control panel shows all four figures on its main page.

2. Note your PHP and MySQL versions

If your site runs on PHP 7.4 and the new server defaults to PHP 8.3, an old plugin or theme can throw a fatal error the moment it loads. You want the new host to be able to match your current version first, then upgrade deliberately afterwards. Ask before you buy.

3. List every email account on the domain

This is the single most-forgotten item. Log into your current control panel, open the email accounts list, and write down every address, its quota, and any forwarders or autoresponders attached to it. Mail is not stored in your website files — it lives separately, and it does not come across when you copy the site.

4. Find out where your domain is registered

Your registrar and your host are often two different companies. You need registrar login access to change nameservers or DNS records. If you don’t know who the registrar is, a WHOIS lookup on your domain will tell you. Sort this out now, not on migration day. Our domain registration and transfer service page explains the difference between the two if it’s unclear.

5. Check for anything unusual

Ask yourself — and your developer, if you have one — whether the site uses any of these:

• Cron jobs or scheduled tasks
• Custom .htaccess rules or redirects
• A dedicated or static IP address
• Third-party services that whitelist your server’s IP (payment gateways, SMS APIs, bank integrations)
• Subdomains pointing to other applications
• Non-standard PHP extensions or higher-than-default memory limits

Every one of these has to be recreated on the new server by hand. None of them travel with a file copy.

Part 2 — Before you start the move

6. Take a full backup and download it

Not a backup that lives on the old server. A backup on your own laptop or in your own cloud storage. Files and database both. If the migration goes badly and you’ve also cancelled the old account, a backup sitting on the old server is worth nothing.

7. Verify the backup opens

A corrupt archive that nobody tested is not a backup. Unzip it. Check the database dump is a real SQL file with your table names in it, not a 0 KB error page.

8. Lower your DNS TTL to 300 seconds

Do this at least 24 hours before the switch. TTL (time to live) tells the internet how long to cache your DNS records. If it’s set to 86400, some networks will keep sending visitors to the old server for a full day after you switch. Drop it to 300 and the changeover takes minutes instead. Raise it back afterwards.

9. Record your current DNS records

Screenshot or export the whole zone: A records, CNAMEs, MX records for mail, TXT records for SPF, DKIM and DMARC, and anything else sitting there. You will need to recreate these, and a missing TXT record is how a company’s email starts landing in spam folders a week later.

10. Note the expiry date on your SSL certificate

Certificates are tied to the server, not the domain. You either reissue on the new server or install the existing certificate there. Either way, plan it — a site that loads with a browser security warning loses visitors immediately. See SSL certificates for the options, or our guide on what an SSL certificate actually does.

11. Freeze content changes

Tell everyone who publishes to the site to stop for the duration. If someone adds a blog post or processes an order on the old server after you’ve copied the database, that work is lost when DNS switches. For a busy e-commerce site, schedule the move for your quietest hours.

Part 3 — On the new server, before DNS

12. Recreate every email account first

Create each mailbox on the new server with the same address before you switch MX records. Then copy existing mail across with IMAP — most control panels and desktop mail clients can do this by connecting to both servers at once. Do this before the switch so no mail arrives at a mailbox that doesn’t exist yet.

13. Match the PHP version

Set the new account to the same PHP version the site runs on today. Upgrade later, as a separate change, so that if something breaks you know which change caused it.

14. Test the site properly before switching DNS

Edit the hosts file on your own computer to point your domain at the new server’s IP. Your browser will then load the new server while the rest of the world still sees the old one. Click through the real site: homepage, contact form, login, checkout, a few inner pages. This is the step that catches broken database connections and missing files, and it costs you nothing.

15. Test the contact form and any payments

Forms fail silently after a migration more often than anything else, usually because the new server sends mail differently. Submit a real test enquiry and confirm it arrives. If you take payments, run a test transaction.

16. Recreate cron jobs, redirects and custom rules

From the list you made in step 5. Copy the .htaccess file across and read it — old redirects in there are often load-bearing for SEO.

17. Install the SSL certificate on the new server

Before DNS switches, so that the moment traffic arrives it is already encrypted.

Part 4 — Switching and afterwards

18. Switch DNS, then watch

Change nameservers or the A record and MX records. With a 300-second TTL most visitors move over within minutes, though full worldwide propagation can still take up to 48 hours in the worst case.

19. Keep the old hosting for at least a week

Do not cancel on day one. Keep it running and paid for seven to fourteen days. If something surfaces — a missing file, a mail folder nobody copied — the original is still there. This single decision turns a disaster into a five-minute fix.

20. Check Search Console and your analytics

For the first fortnight, watch for a spike in crawl errors or 404s in Google Search Console, and check that your analytics traffic looks normal. A correctly executed migration on the same domain should have no lasting effect on rankings at all. A drop usually means a redirect or a robots rule didn’t come across — and it’s fixable if you spot it early.

A short version you can copy

• Audit disk, database, bandwidth, PHP version
• List all email accounts, forwarders and autoresponders
• Confirm registrar access
• List cron jobs, redirects, whitelisted IPs, subdomains
• Full backup, downloaded and verified
• TTL down to 300, 24 hours ahead
• Export all DNS records
• Recreate mailboxes on the new server, copy mail over IMAP
• Match PHP version
• Test via hosts file: pages, forms, login, checkout
• Install SSL
• Recreate crons and .htaccess
• Switch DNS
• Keep old host 7–14 days
• Monitor Search Console for a fortnight

Frequently asked questions

How long before the move should I start preparing?

A week is comfortable for a small business site. The only hard timing requirement is lowering your DNS TTL at least 24 hours beforehand, because the change itself has to propagate before it helps you.

Will moving hosts hurt my Google rankings?

Not if the domain, URLs and content stay the same. Google indexes URLs, not servers. Rankings move after a migration when URLs change without redirects, when pages go missing, or when the site is much slower on the new host — not because of the move itself.

Do I have to transfer my domain as well?

No. Hosting and domain registration are separate services and can stay with different companies. You only need to point the domain at the new host. Many people do consolidate both in one place afterwards simply because it’s easier to manage.

What happens to my email during the migration?

If you recreate the mailboxes on the new server before switching MX records, nothing is lost — mail arriving during the changeover goes to whichever server that sender’s DNS cache points at, and both are accepting mail. If you switch MX records to a server with no mailboxes set up, messages bounce. That’s why step 12 comes before step 18.

Can I do this myself, or do I need a developer?

A straightforward WordPress or static site on shared hosting is well within reach of a confident non-developer who follows the checklist. A site with a custom application, payment integrations or a large database is worth handing to someone who has done it before.

We’ll do it for you

Salasar Hosting migrates websites and email for new customers as part of setting up the account — we work through this checklist with you, test on the new server before anything switches, and keep an eye on it afterwards. Whether you’re moving to shared hosting, a VPS or a dedicated server, the process is the same.

Call +91 99620 05753 or send us the details of your current setup and we’ll tell you honestly what the move involves.