Migrating WordPress Sites

These tutorials compliment my WordCamp Seattle 2014 workshop entitled Migrating WordPress Sites, where I discuss three different ways of moving WordPress sites including when, why, and how we use each method.

This is article 1 of 7 in a series on Migrating WordPress sites.

Why Should I Care About Moving WordPress Sites?

As someone who works with WordPress constantly, understanding WordPress site moves is really important to me, but I think this will be most useful to you if you’re interested in:

• Changing hosts for an existing site,
• Cloning WordPress sites to local, or staging, development environments,
• Getting a better understanding of the core components powering a WordPress site.

WordPress Site Migration Methods:

Here are links to complete instructions and more information about each site migration method:

1. Moving WordPress Sites using PHPMyAdmin & FTP
2. Moving WordPress Sites using BackupBuddy
3. Moving WordPress Sites using WP Migrate DB Pro

Back when I started with WordPress, moving sites was almost always a manual process, like the PHPMyAdmin & FTP method we’ll discuss.  That is, unless you could sweet talk your host into moving your site for you.

Luckily, now there are a wealth of robust plugins and other ways that anyone can use to migrate WordPress sites.  The three methods we’re covering are simply what we’re using now.

So, if you have a favorite method, or variant on one of these methods, please share it in the comments.

Site Migration Foundations

Before we get started with actually migrating WordPress sites, let’s quickly talk about some terms and concepts that you’ll find throughout these tutorials, then we’ll discuss a bit about DNS, what it is and how it works, followed by some tricks you can use to make migrations easier.

Terms

Throughout these tutorials I refer to sites either as:

• Source = the domain or server you’re moving from.
• Target = the domain or server that you’re moving to.

I’ll also use a few other terms that may be a bit scary, depending on your experience:

• Serialized data = how WordPress stores options, settings, and meta information directly in the database.
• Credentials = info you need to access a resource, such as your WordPress, or hosting account, logins.
• Backup = something most people don’t do until it’s too late.

DNS Crash Course

DNS stands for Domain Name System, which is in charge of translating our fancy domain names into the IP addresses belonging to the servers, or networks, on the Net that power these sites.

If you’re unsure how DNS works, check out our DNS Crash Course.

Hosts Files

Hosts files can be used to force domain traffic to go to a specific server or computer.  This is super-handy when moving production sites, or setting up local development environments.

For more info, read Editing Hosts Files to Direct Domain Traffic.

Serialized Data

As mentioned above, WordPress stores options and meta information in the database as serialized data. On Andrew Nacin’s blog post, WordPress serializes options and meta for you, he describes serialized data like so:

In the most basic use case, serialization is a way to store arrays and objects directly in the database, which can only store numbers, text, and dates. Serialization takes an array and turns it into a serialized string. For example:

$data = array( 'apple', 'banana', 'orange' ); echo serialize( $data ); // Result is a string we can unserialize into an array: // a:3:{i:0;s:5:"apple";i:1;s:6:"banana";i:2;s:6:"orange";}

Serializing data is a way of storing large amounts of related data efficiently. The important thing to remember about serialized data when migrating sites is that you can’t simply do a database-wide search and replace for URLs without using a tool that can unserialize the data stored in meta and options, making the replacements, and re-serializing it.

The reason for this is that serialized data is stored in a very specific format and is dependent on the length of the strings being serialized.  So, if you did a standard database-wide search and replace for domain.com with mydomain.com, you’d likely break the site because the replaced string (domain name) contains more characters than the original.

For this reason, it’s really helpful to use a tool like BackupBuddy or WP Migrate DB Pro if your domain will change at all.  These tools take care of unserializing the data, updating it, and re-entering it in the database correctly.

There are also WordPress plugins that can handle search and replace of serialized data within your database, such as:

• WP Migrate DB
• BackupBuddy
• Better Search and Replace

If you’re migrating a site between hosts and the domain name (URLs) won’t change, you don’t have to worry about the serialized data issue.

WP Site Migration Checklist (General)

While each of the site migration methods we’ll cover has it’s own specific set of instructions, the gist of each method is the same.

Here’s a general checklist I use when migrating sites, regardless of the tools or tech involved:

1. If moving a site that’s already live from one server to another, try to lower the domain’s TTL values to 300 or 600 seconds (5 or 10 minutes), at least 24 hours prior to scheduled move to facilitate quicker DNS propagation.
2. Backup the database of the source site.
3. Backup all files associate with the source site.
4. Note IP address of source site and keep it handy, should you need it later.
5. Gather all credentials for target hosting server, including: hosting control panel access (Plesk, cPanel, etc), FTP/SFTP/SSH.
6. Create an empty database on target server along with a user that has full access to the new database, then note all credentials including: database name, user name, password, host.
7. Import source database to target host.
8. Import source files to target host.
9. If DNS isn’t pointed to target server yet, change hosts file on your local machine to map domain to target host’s IP.
10. If changing URLs (ex. mydomain.com to yourdomain.com), make sure to use a tool to search and replace old URLs for new URLs to protect serialized data.
11. Connect database to files by entering target database credentials in wp-config.php.
12. Test site on new server.
13. If broken, breathe first, then troubleshoot.
14. Set target site’s search engine visibility under Settings > Reading, if it’s not live yet.
15. Need to block web traffic except for logged-in users? Install a good Maintenance Mode plugin, activate, and configure.
16. When everything’s tested and you’re ready to launch, make sure site’s out of maintenance mode, is not blocking search engines, and update public DNS to point the domain’s web traffic to the target server.
17. Wait for DNS to propagate or edit your Hosts file to direct domain traffic to the target server.
18. Test.
19. Troubleshoot, if necessary.
20. Once everything’s working, backup again.

Now that you’ve got a good overview and some foundation terminology, let’s move on to the DNS Crash Course.