Migrating a WordPress website without losing data and configuration

Migrating a website to a new host is a very common action for all those who manage WordPress websites.

This operation is performed not only to move the site from a public server, but also to have a copy of the site on a private server (usually local) for development and testing configurations.

First step: Analyze what to migrate and its destination.

First, let’s review several items:

• The number and size of files. Is there enough space and inodes at the destination?
• Database: its version and size. Will it need to be split into smaller parts to upload without issues? Does it exceed the capacity typically supported by MySQL? Will there be encoding change problems?
• PHP version: Could the software cause problems?
• PHP libraries: Are there plugins that use specific libraries that might not be present on the destination server?
• HTTPS: Should we request a certificate on the destination hosting?
• DNS: Do we have access? Can we modify the TTL?

And of course, we will ensure that we have sufficient credentials at both sites to access resources via FTP and an SQL management system.

Second step: Configure

To save time, first and foremost, we configure the destination server.

• Create a space with the domain we will be using.
• Request the HTTPS certificate (in the case of Let’s Encrypt, a wildcard can be requested before the domain points to the new server).
• Lower the TTL of the main A record and www in the DNS to a minimum. This ensures that when we change the IP address referenced by the domain in the DNS, the change is as fast as possible.
• If the website sends emails, ensure that the new server can send emails on behalf of that domain, and that the SPF record allows email outbound from the new IP. You can also configure an SMTP.

Third step: Download

If we are changing the site’s hosting, the ideal starting point for this step would be to instruct the site administrator not to make any changes. If other users can make changes to the website, a method should be implemented to temporarily prevent them from doing so.

In this case, we are going to “take” an exact copy of the website, and we do not want inconsistencies in the data, which is why we prevent changes. However, if you are very familiar with how the site works, you can first download everything that will not be modified and leave for last what forces us to avoid changes, so that the site remains operational for as long as possible.

For example, for a WooCommerce site, we can download all files via FTP and upload them to the new server (fourth step). Once this is done, we proceed to prevent changes to the site by temporarily deactivating the store and notifying the administrator. When this is complete, we transfer:

• The database.
• The wp-content/uploads/(current year)/(current month) folder.

If we are changing the site’s hosting, leave the old site with the change lock in place, so that it cannot be confused with the new site under any circumstances.

If we are not changing hosting and it is only a private copy with no publication intentions, there is no need to block changes at any point.

Fourth step: Upload

We upload all files via FTP and the database to the new hosting that we had already pre-configured in the second step.

All that remains is to:

• Configure the wp-config file with the new server’s data.
• Test that the site functions correctly; if it had a caching system, it may need to be reconfigured.
• Undo the change lock you applied in the third step.

And once this is done, and only if everything is working correctly:

• Change the IP in the DNS and increase the TTL again.

Site published

In this way, your site can change hosting with absolutely zero downtime. The only characteristic is that site editing has been blocked for a certain period of time.

This is a very common operation for any service provider related to websites and WordPress sites.

A migration should never result in data loss. A migration could cause software changes if there are incompatibilities that need to be resolved by modifying the code.

In any case, by following a secure migration protocol, such as the one described here, we will detect potential problems before it is too late.