Migrating a WordPress site from another provider

Almost every WordPress migration breaks in the same place: the order is wrong. The domain gets repointed first, the files start uploading afterwards, and the site sits half-finished for hours in between. The correct order is the reverse — copy first, verify second, DNS last. Below is how to apply that order on the Plesk-based web hosting plans.

List what has to move before you move anything

A WordPress site is four separate pieces, and three of them are easy to forget:

• The files. What really matters is the wp-content directory: themes, plugins and the media library live there. The core files can just as well come from a clean install on the new side.
• The database. Posts, settings, users and all plugin data are in here.
• The mailboxes. If the old provider hosts mailboxes on your domain, they do not travel inside a site backup; they are recreated on the new side.
• Scheduled jobs and DNS records. Cron jobs defined in the old panel and records such as MX and TXT disappear quietly after the switch if nobody carries them over.

The migration, step by step

1. Take a complete copy of the files and the database from the old provider. Use its backup feature if it has one; otherwise pull the files over FTP and export the database from phpMyAdmin.
2. Add your domain to the new plan and create an empty database plus a user with rights to that database only. Write the username and password down.
3. Upload the files to the domain's document root with Plesk's file manager or over FTP. Uploading one archive and extracting it on the server is far faster than sending thousands of small files one by one.
4. Import the database into the new database through phpMyAdmin.
5. Update the database credentials in the site's configuration file with the new values.
6. Verify the site without touching DNS; how to do that is below.
7. If the verification is clean, repoint the domain's A record to the new server.
8. Install the SSL certificate on the new side and turn on the HTTPS redirect.

There is a reason step eight comes last: free certificates are validated over the domain itself, so they cannot be issued before DNS has moved. The detail is in installing SSL in Plesk.

While transferring the database

On large databases you will hit phpMyAdmin's upload size limit. If you have command line access, exporting with compression both gets past the limit and speeds the transfer up:

mysqldump --single-transaction --default-character-set=utf8mb4 \
  -u user -p database | gzip > site.sql.gz

Naming the character set explicitly matters. Most of the mangled characters that show up after a migration come from an export taken with a different character set, and fixing them once the data is in is tedious work.

The four lines that change in the configuration file

Four values in wp-config.php in the WordPress root are updated for the new server: the database name, the database user, the password and the database host. On most shared installs the fourth stays as localhost, but if the old provider had a different value there, do not copy it over blindly.

Note the PHP version before you move

The most common cause of a white screen after a migration is not the database but a difference in PHP version. If the old server has been running an old PHP release for years, an unmaintained theme or plugin will throw errors on a newer one. Note the PHP version the old site runs on before you start.

In Plesk the PHP version is selected per domain. If the site errors on first load, before hunting for the guilty plugin set the version close to the old one and confirm the site comes up; then update the plugins and raise the version step by step.

Verifying the site before you change DNS

Migrations blow up in production because this step gets skipped. The way to open the site on the new server without repointing the domain is to add a temporary line to your own computer's hosts file:

203.0.113.10  example.com www.example.com

The address on the left is the new server's IP, the names on the right are your domain. That line affects only your machine; visitors still see the old site. With it in place, open the home page, an inner page, the search box, the contact form and the admin area one by one. Remember to delete the line when you are done.

Addresses: do not run a plain search and replace

If the domain is changing too, the old addresses in the database have to be updated. Here is the trap: WordPress stores some settings as serialised data, and inside that data the length of each string is recorded separately. A plain search-and-replace query changes the text but leaves the recorded length wrong; the result is widget settings that vanish silently and plugin screens that will not open. Use a migration tool or a search-and-replace script that understands serialised data.

If the domain is not changing, you do not need this step at all.

After the switch

Do not close the old plan immediately; leave it running for at least a week, because the last visitors and messages keep landing on the old server during that window. On the new side, save the permalink settings once, send a real message through the contact form, and set the backup routine up on day one — that is the most commonly skipped step after a migration.

What changes on the resource side, how many databases and how much disk you will need, is collected separately in the WordPress hosting guide.