Yesterday evening, I had to take some time to migrate my site to a new server because I had outgrown the service on which I started.
While doing so, I realized I’ve never bothered to share my WordPress site migration process.
Honestly, there’s nothing particularly unique about it. Furthermore, when it comes to deploying things to staging, I’ll often use tools that interface with my GitHub account to push out the differentials.
But when it comes to move a single site installation from one server to another, I typically follow the same process.
My Single Site WordPress Site Migration
Generally speaking, I follow the same steps that I do every single time.
Backing Up The Main Site
First, any plugins that have the ability to export settings, I will do that and then make sure that I store them in a place that I can easily retrieve.
Next, I download:
- The `themes` directory
- The `uploads` directory
- The `plugins` directory
After that, I’ll do a WordPress export just in case. In a previous post, I’ve discussed the WP DB Migrate Pro plugin, and though I’m a big fan, using the free version is good, too and I prefer it to the WordPress Importer / Exporter.
Spinning Up The New Site
After that, I’ll hop over to the new site and create the database, the database user, and the credentials that are needed to install WordPress.
Assuming that I’m installing the same version of WordPress as the initial site, I’ll then download a copy of WordPress and install it using the database and credentials I just created
Beginning The Migration
From here, I’ll normally go ahead and copy the `themes` directory, the `uploads` directory, and the `plugins` directory to the new installation. After that, I’ll active the themes and the the plugins as well as import any export data from the plugins from the previous site.
The only exception is performance / caching plugins. I usually wait until after the migration is complete to activate them.
I don’t bother with menus, widgets, or anything like that since that comes with the final step.
Importing The Database
Finally, I’ll hop into my database front end and import the SQL that WP DB Migrate generated. This usually takes just a couple of minutes (but is obviously dependent on the size of the site).
Once the import is done, every thing should be good to go and the site should be ready. After that, it’s a matter of updating your name servers.
A Few Gotchas
As with anything technical related, there are always a few things that you need to be aware of when performing a migration:
- When you’re setting up a site on a new server, it often wants to treat the site’s URL as `http://126.96.36.199` or whatever IP address your site resides. That’s fine – leave it as such. Importing the database will update that.
- Unless you use a service that resolves a name server change quickly, then I recommend waiting to do this until night or until a weekend when there’s a lower traffic pattern.
- If you have any tertiary services such as email, analytics, advertisements, etc. or anything that’s domain dependent, remember to update them as soon as the name servers kick over. Otherwise, you run the risk of losing out on email, losing analytics, or losing whatever other data depends on the domain.
The Best Way To Migrate?
Everyone has their strategies and this certainly isn’t the de-facto way of doing it.
For example, when I’m working on projects for clients, I normally have a staging server and will deploy diffs from GitHub (or whatever source control we’re using) to the server.
But I’ve done enough migrations of my own server to lock down a process that can usually be done within an hour to an hour and a half (face it: the `uploads` directory takes time to download and upload :)).
That said, suggestions always welcome so feel free to leave ’em in the comments.