Migrating WordPress Sites with Wordmove

global:
  sql_adapter: wpcli

local:
  [...]

production:
  [...]

staging:
  [...]

oldhost:
  [...]

As you can see above, we're defining our global settings using the global parameter, then defining 4 different environments as local, production, staging, and oldhost.

By defining these different environments, we can easily push or pull the content to or from different locations. This means that with a single command, we can pull the site's files and database to our local development environment, then use another command to push them wherever we see fit.

Configuring Production and Staging Environments

Let's start creating our configuration for our production and staging environments that are being moved to Pagely. To do so, we'll need a few different items:

• The publicly-accessibly URL where WordPress will live (http://example.com).
• The directory on the server that the WordPress installation is located in.
• Database configuration such as the database name, user, password, and host.

With those items in mind, let's get started on obtaining all of the required information that will be needed.

Getting Your Site's Server Path

1. Begin by logging into your server via SSH.
2. Next, access your site's root directory with the following command:

   cd ~/sites/example.com

3. Once inside the site's root directory, issue the following command to get the site's absolute path on the server:

   pwd -P

On a Pagely VPS/Enterprise account, your path will look something like this:

/data/sXXXXXX/domXXXXX/domXXXXX

Be sure to write your path down somewhere, as you'll need it later when configuring Wordmove.

Getting Your Database Configuration Details

Now it's time to get our WordPress site's database connection details. Let's get started.

1. If you're not still connected over SSH from the previous section in this article, go ahead and connect to the server via SSH and access your site's root directory like so:

   cd ~/sites/example.com

2. Next, let's use a little bit of CLI magic to get all of our database details from the wp-config-hosting.php file:

   cat wp-config-hosting.php | grep DB_

Upon running the command in step 2, you should see several lines of output that contain your database name, user, password, and host as DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.

Don't forget to make a note of these. We'll need them later.

Configuring Environment Details

Now that we have all of the details that we need, let's go ahead and put together a configuration file. Create a new movefile.yml file where your WordPress site will live locally on your computer, replacing all of the red text with the values that we gathered earlier:

global:
  sql_adapter: wpcli

production:
  vhost: http://example.com
  wordpress_path: /data/sXXXXXX/domXXXXX/domXXXXX

  database:
    name: db_domXXXXX
    user: db_domXXXXX
    password: ThisIsMyPassword!
    host: vps-virginia-aurora-7-cluster.cluster-xxxxxxxxx.us-east-1.rds.amazonaws.com

  ssh:
    host: sXXXXXX.pXXX.sites.pressdns.com
    user: client_exampleuser

  exclude:
    - '.git/'
    - '.gitignore'
    - '.gitmodules'
    - '.env'
    - 'node_modules/'
    - 'bin/'
    - 'tmp/*'
    - 'Gemfile*'
    - 'Movefile'
    - 'movefile'
    - 'movefile.yml'
    - 'movefile.yaml'
    - 'wp-config.php'
    - 'wp-content/*.sql.gz'
    - '*.orig'
    - 'wp-*.php'
    - 'xmlrpc.php'
    - 'wp-admin/'
    - 'wp-includes/'
    - 'wp-content/mu-plugins/pagely*'
    - 'db-config.php'
    - 'index.php'

Excluding Files

In the example from the previous section, you'll notice that we have a section labeled exclude. This allows us to prevent certain files such as configuration/build files, WordPress core files, and the core Pagely plugin from being pushed or pulled.

Adding Additional Environments

To add additional environments, all we need to do is add additional configuration blocks for each environment that we want to use. At a minimum, you'll want to add a local environment and in the case of migrating a WordPress site from one host to another. With the exception of local, you can use any name you want.

For example, if we have 3 environments named local, production, and oldhost, our configuration would look something like this:

global:
  sql_adapter: wpcli

local:
  vhost: http://example.localhost
  wordpress_path: /my/local/path

  database:
    [...]

  exclude:
    [...]

oldhost:
  vhost: http://oldhost.example.com
  wordpress_path: /path/on/old/host

  database:
    [...]

  ssh:
    [...]

  exclude:
    [...]

production:
  vhost: http://example.com
  wordpress_path: /data/sXXXXXX/domXXXXX/domXXXXX

  database:
    [...]

  ssh:
    [...]

  exclude:
    [...]

FTP-Only Hosts

In all of our previous examples, we're telling Wordmove to connect over SSH. But what if the old host only supports FTP? Simply replace the ssh section with a ftp section like this:

ftp:
  user: example_user
  password: my_password
  host: example.com
  port: 21
  scheme: ftps

For more information on the the available FTP options, take a look at the official Wordmove documentation.

Performing the WordPress Site Migration

Now that we're finished adding all of our environments to our Wordmove configuration, it's time for us to perform the migration from the old host to our new host.

1. Begin by opening up a new terminal window and navigating to the location of your movefile.yml file.

   cd /path/to/my/movefile/location

2. Next, let's use the Wordmove CLI to pull a full copy of our site from the old host to our local environment like this:

   wordmove pull --all --environment=oldhost

   As you can see, we're telling Wordmove to pull everything from the environment that we defined in the configuration file as oldhost.
3. Did everything pull successfully from the old host? Great! Let's test pushing it to our production environment to make sure everything goes well before we commit to it.

   wordmove push --all --environment=production --simulate

   Inside this command, you'll see that we're pushing everything up to our production environment.
   
   For safety purposes, we also used the --simulate parameter. This parameter ensures that everything goes well before actually pushing the changes to the server. When changing any configuration, it's always a good idea to simulate your actions before actually performing them.
4. If the simulation went well, all there is to do now is to remove the simulation parameter and push our site to the new environment!

   wordmove push --all --environment=production

That's it! Your push should complete in just a few moments. Once it's finished, don't forget to take a good look over it to ensure that everything went according to plan!