What to check before you move a website

What to check before you move a website

Before you move a website to a new host, you need a verified backup, a record of your current DNS and email routing, a lowered TTL, and a tested copy of the site running on the new server before you touch a nameserver. Skip any of those and a move that should be invisible to visitors turns into a day of firefighting, usually over email rather than the website itself.

This is the first step in moving a site to Hostworld. It assumes you have chosen, or are close to choosing, a hosting product with us, but you have not cancelled anything with your current host and you have not changed any DNS yet. If that is not you yet, this guide still stands on its own: everything here applies whichever host you are moving to.

Before you start

You will need access to your current hosting control panel, access to wherever your domain's DNS is managed (this might be your registrar or a separate DNS provider), and enough time to run old and new hosting side by side for a week or two. A website move is not something to compress into an afternoon if you also rely on email at that domain. Set aside the time properly and none of the following steps are difficult.

The single biggest cause of a bad migration is order. Not a missing skill, just doing things in the wrong sequence: switching DNS before testing, or cancelling the old account before confirming the new one works. Everything below is written in the order that avoids that.

Step 1: Take a full, verified backup

Do not start moving anything before this is done. A migration should be reversible, and a backup is what makes it reversible. If something goes wrong halfway through, you want to be able to undo, not rebuild from memory.

A backup for a website move needs to cover more than the files people usually think of:

• Website files
• Database (or databases, if there is more than one)
• Email, mailboxes and mail settings
• Your DNS zone (covered separately in Step 2)
• SSL certificates, if you manage your own rather than using an automatically issued one
• Cron jobs, if your site relies on any scheduled tasks

If your current hosting is cPanel-based, a full account backup from that panel will normally include most of these in one archive. Check the settings before you download it: some cPanel backup configurations exclude email by default, and email is exactly the thing you cannot afford to lose.

Store the backup in two places, for example your own computer and a separate cloud storage account. Do not leave the only copy sitting on the server you are about to move away from.

Then test it. An untested backup is not a safety net, it is a guess. If you can, restore it somewhere separate, a local environment or a staging site, and check the site actually comes up and the database connects. This takes half an hour and it is the difference between a recoverable mistake later and a genuine data loss.

Step 2: Export your current DNS zone

Before you change a single DNS record, export the zone file as it stands. This gives you a complete list of every record your domain currently uses: A records, CNAME records, MX records, TXT records for things like SPF or domain verification, and anything else that has accumulated over the years.

Most DNS management panels have an export or "view zone file" option somewhere in the domain's DNS settings. If yours does not offer a clean export, copy every record into a document by hand. It is tedious, but it means that if something is missed later, you have a reference to check against rather than having to reverse-engineer what used to be there.

Step 3: Check where your email is routed

This is the step people skip, and it is the one that causes the most damage. A website move and an email move are two different things, and changing nameservers affects both at once whether you meant it to or not.

Look at your domain's MX records now, before anything else changes. Note down what they point to. There are three common situations:

• Email is hosted with your current web host, alongside the site. In this case, moving the site to Hostworld and pointing your domain at Hostworld nameservers will move email too, and you need to set up mailboxes on the new hosting before cutover so nothing is dropped in between.
• Email is hosted separately, for example with a dedicated email provider, and only the website is with your current host. In this case, changing nameservers to Hostworld's without preserving those MX records will silently break inbound mail, even though the website works perfectly.
• You are not sure. If you cannot find where your email is currently routed, find out before you go any further. A website that looks fine while every contact form and order confirmation quietly fails to arrive is a worse outcome than a site being offline, because nobody notices until a customer complains.

If email needs to keep working exactly as it does now, make sure the same MX records are recreated once your domain is pointed at Hostworld's nameservers, or that mail stays with its current provider and only the A record for the website changes. Do not assume a nameserver switch leaves email alone.

Step 4: Lower your DNS TTL, at least two days ahead

TTL (time to live) controls how long other computers on the internet are allowed to cache your DNS records before checking again. If your A record has a TTL of 24 hours, a change you make on cutover day can take up to a full day to reach some visitors, during which they are served whichever server the old record pointed to.

At least 48 hours before you plan to switch anything over, log in to wherever your DNS is managed and lower the TTL on your A record, any CNAME records, and your MX records to 300 seconds (5 minutes). This does not change what the records point to, only how long they are cached. Once the old, longer TTL has expired everywhere, and 48 hours is a safe margin for that, any change you make afterwards reaches visitors within minutes rather than hours.

This single step is what turns a migration with a visible outage into one nobody notices.

Step 5: Note your current environment

If your site is built on something like WordPress, or relies on a specific PHP version, write down what you are currently running: PHP version, WordPress version, active theme, active plugins and their versions, permalink structure, and any customisations in configuration files such as wp-config.php.

You will want to match this on the new hosting rather than discover a mismatch after the move. A plugin built against an older PHP version, or a permalink structure that was never re-saved on the new site, are common causes of a site that "moved fine" but behaves differently once it is live.

Step 6: Test the new site before you switch DNS

Get the site fully working on the new hosting while your domain still points at the old one. Nobody else needs to see this: you can view the new copy by editing your own computer's hosts file to point your domain at the new server's IP address just for you, or by using whatever preview or temporary URL your new host provides.

Check the pages load, forms submit, the database connects, and anything dynamic behaves as it should. This is the point to catch the environment mismatches from Step 5, while the live site is still safely on the old server and nothing depends on the new one yet.

Step 7: Map your existing URLs, if search rankings matter to you

If the site has been indexed by search engines and the move changes any URL structure, list out your important existing URLs and where each one should redirect to on the new site. This is a pre-move task, not something to sort out afterwards: doing it in advance means the redirects can go live at the same time as the new site, rather than leaving a gap where old links return errors.

Step 8: Keep the old hosting running

Once the new site is tested and DNS is pointed over, resist cancelling the old hosting account. Keep it running for at least a week, ideally closer to two, while you confirm the new hosting is stable under real traffic and real email load. Cancelling early is the single most expensive mistake in a migration, because it turns every problem that would otherwise be a quick revert into something you have to rebuild from a backup.

Once you are confident, retrieve anything left on the old server (any orders, uploads or messages that arrived after cutover), take one final backup from the old hosting as a precaution, and only then cancel it.

Step 9: Point your domain at Hostworld, and raise TTL back afterwards

When Steps 1 to 6 are done and the new site checks out, change your domain's nameservers at your registrar to:

• ns1.serverworld.uk
• ns2.serverworld.uk
• ns3.serverworld.uk
• ns4.serverworld.uk

Because you lowered TTL in Step 4, this should reach visitors within minutes rather than hours. Once you are confident everything has settled and there are no issues, raise TTL back to a normal value, such as one hour or 24 hours. A low TTL left in place indefinitely adds a small overhead to every visitor's DNS lookup for no ongoing benefit once the move is stable.

What next

With a verified backup, your DNS zone documented, email routing confirmed, and TTL already lowered, you are ready to move the site itself into a Hostworld cPanel account and bring your mailboxes and database across. Our migration guides cover that in more detail, and our backup guides are worth reading alongside this if you have not restored a backup before and want to see how it is done.

If anything about your setup does not fit neatly into the steps above, for example a mail provider you are not sure how to check, or a database structure you are not confident backing up yourself, open a support ticket and describe what you have. It is far cheaper to ask before you move than to unpick a problem afterwards.