Moving a WordPress website between servers is usually fairly straightforward. The difficult part is making sure everything works on the new server before directing visitors to it.
I’ve migrated WordPress sites between hosting providers, and the approach I prefer is to get the entire website working on the new server before making any DNS changes.
That way, the existing website can continue running while I test the replacement.
The trick is using the computer’s hosts file to access the new server without changing where the domain points for everybody else.
Creating a backup
The first step is to get a copy of the existing website.
For a typical WordPress installation, I need the database and files, particularly everything under wp-content.
I’ve used Duplicator
For larger sites, the media directory can be particularly big, so it may be easier to transfer the files separately.
Before starting, I also check for anything that isn’t included in a standard WordPress backup, such as custom server configuration, scheduled tasks or external services.
Setting up the new server
Once I have the backup, I set up the new hosting environment.
Depending on the server, that might mean configuring Nginx, PHP, a database and SSL certificates, or using a tool such as EasyEngine to manage the installation.
The important thing is that the new environment is ready to serve the website before I start the migration.
I then restore the database and files onto the new server.
At this point, the domain still points to the original server, so visitors continue using the existing website.
Testing with the hosts file
This is the part that makes the migration much easier.
Every computer has a hosts file which can be used to override DNS lookups for particular domains.
On Windows, it’s located at:
1C:\Windows\System32\drivers\etc\hosts
You need to edit the file with administrator permissions.
For example, if the new server has an IP address of 203.0.113.10, you can add:
1203.0.113.10 example.com2203.0.113.10 www.example.com
These are example values rather than a real server.
Now, when I open example.com on that computer, the request is directed to the new server.
Everybody else continues using the original website.
This allows me to test the new installation using the real domain, which is particularly useful for WordPress because so much of its configuration depends on the site’s URL.
The new server still needs to be configured to respond to the domain and present a valid SSL certificate.
If the website is behind Cloudflare, the hosts-file approach connects directly to the new origin, bypassing Cloudflare’s normal proxying. That’s useful for testing the origin, but it also means Cloudflare-specific behaviour needs separate verification.
Checking the website
Before changing DNS, I work through the website and make sure everything is behaving as expected.
I check that pages load, images work, forms submit correctly, and WordPress can access its database.
I also check redirects, permalinks, scheduled tasks and any plugins that rely on external services.
The WordPress administration area is particularly useful for spotting problems which might not be obvious on the frontend.
It’s worth running a Lighthouse test too, especially if the migration involves changing PHP, Nginx or caching configurations.
There’s little point moving a working website to a new server if the replacement performs worse.
Making the switch
Once I’m happy that the new server is working, I can update the DNS records to point the domain to the new server.
For websites that change frequently, I arrange a final synchronisation before the switch.
For example, if visitors can place orders or submit forms, copying the database several hours before changing DNS could mean losing any data created in that period.
I’d normally arrange a short maintenance window or temporarily restrict writes while copying the final changes.
The exact approach depends on the website. A brochure site is much easier to migrate than a busy WooCommerce store.
DNS changes can also take time to propagate because resolvers may retain the previous records until their cached values expire.
For that reason, I leave the original server running until I’m confident traffic is reaching the new one.
After the migration
Once DNS has been updated, I remove the hosts-file overrides and test the website again.
I want to make sure I’m reaching the new server through normal DNS, rather than still seeing it because of my local override.
I also check that SSL is working, emails are being sent, scheduled jobs are running, and the new server is receiving the expected traffic.
If the website uses Cloudflare, I check its cache and proxy settings as well.
Finally, I make sure backups and monitoring are configured on the new server.
Why I prefer this approach
The biggest advantage is that the migration can be tested before visitors are affected.
There’s no need to take the existing website offline just to find out whether the new server works.
It doesn’t guarantee zero downtime, particularly for websites that need a final database synchronisation, but it removes a lot of unnecessary risk.
Most of the work happens while the old website is still serving visitors. When everything is ready, the final switch is relatively small.
And if something goes wrong during testing, the original website is still there.