Moving Your Website to a New Host Without Breaking It

Copying a website to a new host is the part that rarely fails. Files, database, theme and images arrive intact, and most hosting companies will run the transfer for you at no charge. What breaks is everything that pointed at the old server without ever living on it: the DNS records, the email that quietly ran from the same cPanel account, the SSL certificate that does not travel with the files, and the scheduled jobs nobody wrote down. A useful website migration checklist is therefore mostly a list of things that are not inside your website.

The second half of the problem is timing. For some hours after the change, part of your audience reaches the new server and part still reaches the old one, and neither group can tell which. Plan for that window and nobody notices the move. Ignore it and you spend a Monday morning working out why an order exists on a server you were about to cancel.

What actually breaks when you change hosts?

Hosting is sold as a file transfer, and as a file transfer it generally works. The failures cluster in a short list of things configured against the old host rather than stored on it, which means they are invisible in any backup you take.

• DNS records, all of them. Most people change the A record and stop. The zone usually also holds MX records for mail, TXT records for SPF and verification, and CNAMEs for a webmail or booking subdomain. Move the A record alone and the site works while the mail quietly stops.
• Email, if it shared the hosting account. On Malaysian shared hosting this is the normal arrangement: the website and every name@yourcompany.com.my mailbox sit in one cPanel. Cancel the old plan and the mailboxes go with it.
• The certificate. HTTPS is issued to the server, not the domain, so the new host needs its own. Between the DNS change and that certificate being issued, visitors get a browser warning rather than your site — which looks worse than being down.
• Scheduled jobs. Backups, WordPress cron, an overnight export to your accounting system, the script that clears the cache at 3am. None of them are in the database, and they are usually discovered weeks later by their absence.
• The server underneath. A different PHP version, a lower memory limit or a missing extension will break a plugin that has worked for years.
• Addresses written into the database. This one does travel, and that is the problem. Old absolute URLs, a hardcoded server path in a plugin setting, an IP address in a payment gateway’s allowlist: all copied faithfully, all now pointing at the wrong machine.

If the reason for moving is that the site keeps costing more to keep alive, the host may not be the whole story: a site that has become expensive to maintain carries problems that follow it to the new server.

Then there is the window. A DNS change is not a switch being flipped; it is a cached answer being allowed to expire. Every network that looked your domain up recently holds the old address until its time-to-live runs out, so for a stretch afterwards some visitors land on the new host and some on the old one. Both are live, both accept enquiries, and only one has the database you intend to keep.

Google’s instruction is to shorten that window in advance: consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the move. The numbers are ordinary — Cloudflare’s Auto setting is 300 seconds and a DNS-only record goes as low as 60 seconds — but the change has to be made early enough that the old, long TTL has itself expired everywhere first.

A DNS change is not a switch. It is an expiry, and until it finishes you are running two websites.

The website migration checklist

Four stages, in order. Almost all of the work belongs to the first two, which is why a move that is planned takes an afternoon and a move that is improvised takes a fortnight.

1. Before anything is copied

• Write down the whole zone. Export the current DNS records rather than reading them off a screen. You need every record, not the one that serves the website.
• Find out where email actually lives. If the MX records point at the same host as the site, email is part of this project whether you wanted it to be or not.
• Lower the TTL a week ahead, as above, and check afterwards that the lower value is really being served.
• Take a backup you have restored somewhere. An untested backup is a hope. Keep a copy that is on neither the old host nor the new one.
• Match the environment. PHP version, memory limit, database version, any extension a plugin depends on. Ask the new host to match what you have now, and upgrade afterwards as a separate change.

2. Build and test on the new host, before touching DNS

• Reach the new server without moving anyone to it. Google suggests you allow for public testing with a temporary hostname for your new infrastructure (like beta.example.com); editing your own machine’s hosts file does the same job for one person.
• Test the enquiry path end to end, including whether the email actually arrives — not whether the form shows a success message. Those are different tests and only one of them matters.
• Keep the test copy out of search. Use a noindex tag and leave the page crawlable, so the tag can be read. A robots.txt block hides the instruction rather than the page.
• Get the certificate issued before the switch, if the new host can validate ownership without the DNS change. Let’s Encrypt states that up to 5 certificates can be issued per exact same set of identifiers every 7 days, so retrying a failing certificate on launch day can burn the allowance you need an hour later.
• Confirm your Search Console verification survives. Google is blunt: make sure your Search Console verification will continue to work after the hosting move. An HTML file left on the old server takes your access to the data with it.

3. The switchover

• Freeze changes first. Anything published, ordered or submitted on the old host after the database copy exists only there. Announce the freeze internally; this is the step that gets skipped.
• Change the record, then watch both servers. Traffic should drain from one to the other over the TTL you set, not vanish from one instantly.
• Do not cancel the old plan. Google’s wording is the right rule: once the traffic to the old provider reaches zero, you can shut down your old hosting infrastructure. Until then it is your rollback.

4. The first week

• Expect the crawl rate to dip. This is documented and normal: it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days. Do not react to it.
• Send real email and see where it lands. A new host means a new sending IP address, and if your SPF record still authorises the old one your enquiry notifications start going to spam while the website looks perfect.
• Restore what the move interrupted. Backups, uptime monitoring and the update routine all need re-establishing; a maintenance plan worth the name is more than plugin updates, and a migration is the moment it silently stops running.

When something breaks anyway

It will, occasionally, and the recovery is calmer if you have decided in advance what each failure means.

Rolling back is another DNS change, and it is exactly as slow as the one you just made. That is the real argument for a short TTL: not that the switch is quick, but that the mistake is quick to undo. If you must take the site down while you sort something out, Google’s instruction for a closure of a day or two is to return an informational error page with a 503 HTTP response status code — which says “come back” rather than “this is gone”. Do not serve that 503 for robots.txt, which blocks crawling of everything, and do not reach for a 403, 404 or noindex instead: those describe a page that has been removed.

Missing email is the failure that costs money, because nothing looks wrong: the site is up, the form submits, and the enquiries are landing in a mailbox on a server you are about to switch off. Send a test enquiry from an address outside the company on the day of the move, and again three days later.

Frequently asked questions

Where iRevamps fits

A host move is a good moment to find out what a site has accumulated, because every one of those checks has to be made anyway. Most migrations we are asked to run turn into a shorter conversation about whether the new host fixes the actual complaint — a slow site is usually slow because of what it runs, not where it runs. Our website revamp and design service starts with that audit, and if the honest answer is that a straight move will do, we say so.