Cutover day: the order to do things in

Cutover day goes wrong when the DNS change happens before everything else is ready, not because DNS itself is complicated. The safe order is: freeze the old site briefly, run one last sync of files and database, test the new server privately without touching DNS, then change the DNS or nameservers, and keep the old server reachable for a few days afterwards because mail and stray visitors will still find it.

This picks up from a server that already has a working copy of your site: files and database bulk-copied across, and the destination tested to the point where you know the software runs. If you haven't done that part yet, that's a separate step in its own right and this article assumes it's behind you.

Before you start

• DNS TTL should already be low. If you dropped the TTL on your DNS records to something like 300 to 600 seconds at least a day or two before today, resolvers around the internet will pick up your change quickly once you make it. If you didn't lower it in advance, lowering it now doesn't help: a resolver that already cached your record under the old, longer TTL keeps that old TTL for its own copy and won't check again until that expires. There's no shortcut for this one, only planning ahead.
• Mailboxes should already exist on the new server. Every mailbox, forwarder and alias needs to be present before you touch DNS, along with your SPF, DKIM and DMARC records. Recreating mailboxes after the switch is how people lose incoming mail.
• Know who controls your domain. If Hostworld is your registrar, nameserver changes happen in your Hostworld client area. If your domain sits with another registrar, the nameserver change happens on their site, not ours, and we'll come back to that below.
• If you're moving a live cPanel account, know your route. A cPanel-to-cPanel move (Hostworld's own hosting is cPanel, on shared, reseller and WordPress hosting alike) is normally handled with WHM's Transfer Tool, which copies one or more accounts from the old server to the new one. It doesn't clone a whole server, only the accounts you point it at, which is exactly what you want for a single site.
• If your site takes live writes, orders, form submissions, new user registrations, you need a way to stop new writes landing on the old database while you do the final sync. That's what the freeze in Step 1 is for.

Step 1: Freeze the old site

Put the old site into maintenance mode, or otherwise stop it accepting new orders, comments or registrations, for the few minutes it takes to run the final sync. For most sites this is a five-minute window, not an outage day.

The reason this matters: if someone places an order or creates an account on the old server after you've already exported the database for the final copy, that record only exists on the old server. Once DNS points elsewhere, nobody is looking at the old server any more, and that order is gone unless you go back for it manually. Freezing the site closes that gap. If your site is genuinely static, no orders, no comments, no logins, you can skip the freeze; there's nothing for it to protect.

Step 2: Run the final sync

With the old site frozen, copy across anything created or changed since your original bulk transfer: new files, and a fresh export of the database. This is sometimes called a delta sync, because it only needs to catch what's changed rather than repeat the whole transfer.

If you used WHM's Transfer Tool for the original account copy, running it again now for the same account will pick up the current state of files and database in one pass. If you copied things manually, that means a fresh mysqldump of the database and an rsync or similar of any files that changed, then importing that dump on the new server, overwriting the earlier copy.

Once the sync has finished and you've confirmed the new database has the latest orders or entries in it, you can unfreeze the old site if you want to, though there's rarely a reason to: you're about to stop sending traffic to it anyway.

Step 3: Test the new server before you touch DNS

This is the step people skip, and it's the one that turns a quiet migration into a public one. Don't change DNS and then hope the new server behaves. Check it first, privately, using your own computer's hosts file to point only your machine at the new server's IP address while everyone else still reaches the old one.

On Windows, the hosts file is at:

C:\Windows\System32\drivers\etc\hosts

On macOS and Linux, it's at:

/etc/hosts

Open it with administrator or root privileges and add a line mapping your domain to the new server's IP address, for example:

203.0.113.10  yourdomain.co.uk
203.0.113.10  www.yourdomain.co.uk

Save the file, then load your site in a browser as normal. Your computer will now resolve that domain straight to the new server while every other visitor in the world is still hitting the old one, unaffected. Check the pages load, log in and check the admin area, place a test order if you run a store, and check any cron jobs or scheduled tasks are running where you expect. This is the point at which a wrong database connection string or a missing file path shows up, in front of you, rather than in front of customers.

Once you're satisfied it works, remove the line you added to the hosts file. If you leave it in place, your own computer will carry on quietly talking to the new server directly, bypassing DNS, which will make later checks (like confirming DNS has actually switched) misleading.

Step 4: Change the DNS or nameservers

If Hostworld is your registrar, edit the nameserver records for the domain from the domain's details in your Hostworld client area. That screen sends the change through to the registry in the background; there's nothing else to run on our side.

If your domain is registered elsewhere, log in to that registrar's own control panel and update the nameservers there. Whichever registrar it is, the values you enter are:

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

Enter those exactly. A mistyped nameserver takes your site and your mailboxes offline until it's corrected, and it isn't instant to undo.

Be aware that a nameserver change is slower and less predictable than changing a single DNS record like an A record. The TTL on the NS record itself is set at the registry level, not by you, and it's typically around 48 hours. Lowering your own record TTLs in advance doesn't touch this figure. Practically, that means: expect most visitors to be on the new server within hours, but don't be surprised if a small number of resolvers are still pointing at the old one for up to two days. This is normal, not a sign anything has failed.

Step 5: Watch both mailboxes and both servers during propagation

Web traffic tolerates a mixed state well: some visitors on the old server, some on the new, for a while, is not something anyone notices. Email is less forgiving, because during MX propagation a message can genuinely be delivered to either mail server depending on which cached record the sending server happens to be using at that moment.

For at least a week after cutover:

• Check the inbox on the old server as well as the new one.
• Don't delete or disable the old mailboxes.
• Don't cancel or shut down the old hosting yet, even if the new site looks perfectly settled.

This is the concrete reason not to close the old account early: a customer email that lands on the old server three days after you switched DNS is real mail, not a fault, and it needs to be somewhere you can still read it.

Step 6: Raise the TTL back up, and stand the old server down properly

Once things have settled, usually after a week or so of stable operation and no mail turning up on the old server, raise your DNS TTL back to a normal caching value such as 3600 or 86400 seconds. There's no benefit to leaving it low permanently; it only means more DNS lookups for everyone.

Keep the old server reachable for a defined period rather than switching it off the moment DNS changes: a few days at minimum, to cover the mail stragglers described above, longer if you want a genuine rollback option in case something surfaces on the new server that you didn't catch in testing. Only once you're confident, and the old mailboxes have been quiet for several days, should you go ahead and cancel or repurpose the old hosting.

What next

With the domain pointed at our nameservers and the site running on the new server, the next thing worth checking is that the VPS or hosting account itself is configured the way you want long-term, backups scheduled, monitoring in place, and any firewall rules carried across from the old setup. If you're running this on a VPS, our VPS guides cover managing a server day to day through Virtualizor once it's live, and our Linux VPS pages have the current specifications if you're deciding on capacity for the new server. If anything during cutover doesn't match what's described here, or you hit a step that needs a hand, open a support ticket and we'll pick it up from there.