Using WP-CLI To Migrate WordPress to another server or your dev environment

I’m going to cover one way to move a WordPress install from one server to another by using command line tools. This method means you can make this whole process into a shell script if you like.

Why use WP-CLI to migrate WordPress?

There are a lot of ways to move a WordPress site, you can just use Duplicator and move it manually. Or find one of the many plugins that’ll do the whole process for you.

I like using the WP-CLI tool because it gives me a quick way to sync the databases across two servers without having to use an interface. I can do all of my testing on the new live server before actually making the DNS live.

When I’m ready to go live I can change the DNS, fire the script off, lean back and sip coffee.

Preparation

Your ingredients list is as follows:

  • Two servers, SSH access to both and root access to both so you can install WP-CLI and SSH keys, more on that later
  • A new site setup on your new server. I normally use Laravel Forge to do this, it saves a lot of time
  • A fresh database on the new server and the access credentials
  • A backup of your WordPress install, in case things go wrong. I recommend using the duplicator plugin, it’s awesome

Step 1. Install WP-CLI on both servers

Make sure you’ve got WP-CLI installed on both servers. See the WP-CLI installation documentation, it explains the process.

Step 2. Install WordPress on the new server

If you’re using Laravel Forge or some other server management tool you’ll probably be able to install WordPress from there and can skip this step. If you want to learn how to use WP-CLI for installations then read on.

SSH into the new server as a non-root user and cd to the site root. For example:

cd /home/forge/example.com

Installing a fresh copy of WordPress is ideal because it’ll create fresh copies of all of the security salts and leave you with a new car smell. We’ll copy the themes and settings over later.

First, download the latest WordPress:

wp core download

Now we’ll create a config file. You can either replace the values below with your credentials or add --skip-check and use placeholder values. If you use placeholder values then just be sure to edit your wp-config.php file afterwards.

wp core config --dbname=YOUR_DATABASE_NAME --dbuser=YOUR_DATABASE_USER --dbpass=YOUR_DATABASE_PASSWORD

Step 3. Make sure you know the path to your old and new installs

Get the absolute paths for:

  • The site on the old server
  • The site on the new server

The easiest way to pull these out is to cd into the site directory and use the pwd command when you’re in the directory. Sometimes the absolute path is different to the path you typed while changing directory with cd.

Step 4. Copy the database

We can tackle this in a few ways. I like to pull the database from the old server, copy it to a file on the new server, import that to the fresh install and then rename any references required.

On the new server in the root of your WordPress install, which you’ll be in already if you’re following this tutorial, run the command below.

Note: Replace all the bold italic with the appropriate details from your own sites. You’ll be prompted for your root user password. The code block below is all one, very long, line.

ssh root@THE_IP_ADDRESS_OF_YOUR_OLD_SERVER "cd /the/path/to/your/old/wordpress/ > /dev/null&&wp --allow-root db export /tmp/exported-wp-sql.sql > /dev/null"

On the new server run the command below to copy the SQL file across to your new server using scp

scp root@THE_IP_ADDRESS_OF_YOUR_OLD_SERVER:/tmp/exported-wp-sql.sql /tmp/exported-wp-sql.sql

Now use WP-CLI to import the database into your new WordPress install. I like to make this silent but you can remove the --quiet flag if you like.

wp --quiet db import /tmp/exported-wp-sql.sql

Clean up your mess by removing the sql file in your tmp directory

rm /tmp/exported-wp-sql.sql

Explanation of the long SSH command above included at the end of this post if you’re interested, otherwise just enjoy the magic SQL dump.

Bonus Step. Find and replace strings

If you’re moving the site to another domain, or to your local dev environment, then you might want to replace the URLs in the database so WordPress works.

wp search-replace "http://old-url.com" "https://new-url.com"

Step 5. Copy the wp-content folder from the old install to the new

Copying this folder will set up all of your plugins from the old site and the old themes. Don’t worry, we don’t need to use FTP, we’ve got rsync.

Run the line below on the new server, the code block below is one line. I’ve included an example afterwards because Medium’s formatting is confusing.

rsync -r root@THE_IP_ADDRESS_OF_YOUR_OLD_SERVER:/the/path/to/your/old/wordpress/wp-content /the/path/to/your/new/wordpress/

For example this might look like the command below but with a valid IP address:

rsync -r root@123.256.567.300:/var/www/example.com/wp-content /home/forge/example.com/

You can now go get a beverage while it does some copying for you.

Step 6. Test and release

The site should be set up and ready for whatever testing you want to perform. I normally edit my hosts file and point the domain at the new IP.

When you are ready for release you can easily sync the database by running everything in Step 4 and Step 5 again.

I’ve chucked an example update script on Github. I use it to sync the new site or my development site with the latest changes on the old site. I used to use scp instead of rsync but I find rsync is quicker so I’ve replaced scp. The syntax is the same though if you want to use scp instead.

If you have any feedback, different approaches or questions then you can find me on Twitter.


Welcome to the bits I didn’t want to put in the main post

Running commands as root vs non-root

A few of the commands I’ve detailed above use the root user on the old server. For the sake of ease I tend to run all the export commands as root. It’s generally frowned upon to do this because root is such a powerful user so you may wish to substitute the root user with another user for your own uses.

All of the import commands should be run as a non-root user. Otherwise you can have issues with permissions when you’re running the server.

Explanation of the SSH command

This is a little bonus bit of the post to explain the slightly long SSH command to dump the database. There are a few things happening at once.

ssh root@THE_IP_ADDRESS_OF_YOUR_OLD_SERVER "cd /the/path/to/your/old/wordpress/ > /dev/null&&wp --allow-root db /tmp/exported-wp-sql.sql > /dev/null"

First we’ve got the ssh root@THE_IP_ADDRESS_OF_YOUR_OLD_SERVER this simply logs into the terminal on that server, but you probably know that.

Secondly we’ve got a few commands concatenated together with ampersands.

cd /the/path/to/your/old/wordpress/ > /dev/null

Change the folder to the root of the WordPress install but instead of outputting the result to terminal just send it to a blackhole to never be seen again (that’s what > /dev/null is doing).

&&wp --allow-root db export /tmp/exported-wp-sql.sql > /dev/null

The && immediately runs the command above. We ask WP-CLI to allow us to run as root without warnings and export the database to an SQL file somewhere away from the web hosting. Again with > /dev/null to send the output into a blackhole.

Like what you read? Give Devron Baldwin a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.