Before you move: plan and back up
A WordPress site is two things: the files (WordPress itself, your themes, plugins and uploads) and a database that holds your posts, pages and settings. A good move copies both, exactly, and changes nothing else until you have tested the result.
- Make a list. Note your WordPress and PHP versions, active plugins and theme, any custom code, scheduled tasks, redirects, and which services (email, payment gateways, APIs) are tied to the server.
- Take a full backup of the files and the database, and store a copy on your own computer or in cloud storage, not only on the old host.
- Check compatibility. Make sure the new host runs a PHP version your theme and plugins support. Update first if you are far behind.
- Pause changes. Tell anyone who edits the site not to publish, and pause shop orders or form entries during the final copy.
Lower your DNS TTL a day or two ahead
DNS records carry a TTL (time to live): how long other networks may remember an answer before asking again. If your TTL is 24 hours, some visitors keep going to the old server for up to a day after you switch. Lower the TTL on the A record (or on your nameservers' records) to 300 seconds at least as long before the move as the old TTL.
| If your current TTL is | Lower it to 300 seconds at least this long before the move |
|---|---|
| 300 seconds (5 minutes) | Nothing to do |
| 3,600 seconds (1 hour) | 1 hour |
| 14,400 seconds (4 hours) | 4 hours |
| 86,400 seconds (24 hours) | 24 hours |
After the move is stable, raise it again to an hour or more.
Copy the site: three ways
- Ask the new host to do it. The easiest route, and the one with the least that can go wrong. Cloud Cabin's migration team does this on request. Open a ticket after you sign up and we take it from there.
- Use a migration or backup plugin. Plugins such as Duplicator, All-in-One WP Migration and UpdraftPlus package the site and restore it on the new host. They suit small and medium sites.
- Do it by hand. Copy the
wp-contentfolder (and any custom files in the WordPress folder) with SFTP or rsync. Export the database from phpMyAdmin or with WP-CLI and import it on the new host. Editwp-config.phpwith the new database name, user and password.
If the web address changes (a new domain, or http to https), the database also needs its old address replaced with the new one. WP-CLI does this safely, including inside serialised data. Run it as a dry run first:
wp db export before-move.sql
wp search-replace 'https://old-address.example' 'https://new-address.example' --skip-columns=guid --dry-run
WordPress documents the manual route in its guide to moving WordPress (opens in a new tab).
Test the copy before you switch
Your visitors still use the old site, so you can take your time. Preview the new copy by pointing your own computer at the new server: add a line to your computer's hosts file that maps your domain to the new server's IP address, or use the temporary address your host provides. Then check:
- the home page, a few inner pages and your most important page (a shop, a booking form);
- logging in to wp-admin, and saving the permalinks page once if inner pages show a 404;
- contact forms and any emails WordPress sends;
- images and files in the media library;
- that Settings, Reading does not have "Discourage search engines from indexing this site" ticked (it is easy to copy it across by accident).
Remove the hosts-file line when you finish, or you will keep seeing the new server and wonder why a later change does not show.
Switch the DNS and check the SSL certificate
When the copy is right, do a last sync of anything that changed (new orders, new posts). Then change the A record to the new server's IP address, or change your domain's nameservers to the new host's. Email is not affected unless you also change the MX records.
The new host needs an SSL certificate for your domain. Many hosts, Cloud Cabin included, issue free certificates automatically, but they can only do so once the domain points at them. Allow a few minutes after the switch, then load the site over https and look for the padlock.
After the move: what to check
- Keep the old hosting for about a week. If something is missing, it is still there.
- Look at your Search Console and your site's 404 errors for a few days. A move to a new host with the same web addresses does not change your rankings, but broken pages would.
- Purge any caches (plugin cache, CDN) so no visitor sees stale pages.
- Update anything that lists your server's IP address: firewalls, payment providers, API allow-lists.
- Raise the DNS TTL again.
- Take a first backup on the new host and confirm you can restore it.
What about email and the domain itself?
Email lives in its own records and its own place. If your mailboxes are on the old host, copy them across (an IMAP sync preserves folders) before you change the MX records. If your email is with another service entirely, leave the MX records alone and it carries on unaffected. Whichever you do, carry your SPF, DKIM and DMARC records across too (see the email authentication guide).
Moving the domain registration is a separate job, and it does not need to happen on the same day. The domain transfer guide covers .co.uk domains.
Let Cloud Cabin do it for you
Our migration team moves websites, email and databases with minimal downtime. Free migrations are available to new customers on eligible plans. Open a ticket after you sign up and we will take it from there. Every web plan includes cPanel, LiteSpeed caching, daily offsite backups and a free website builder. See WordPress hosting plans.
Frequently asked questions
Copying a small site takes under an hour, and a large one a few hours. The switch then takes effect within minutes if you lowered your TTL beforehand.
Not if your web addresses and content stay the same and the site stays online and fast. Rankings fall when pages disappear or addresses change without redirects, which is why testing before the switch matters.
Not for the move itself, because visitors keep using the old site until you switch. Pause publishing and shop orders during the final copy so nothing is lost.
You can, but it is safer to do it separately. See the domain transfer guide.
