WordPress Site Migration

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.

WordPress SIte Migration

Migrations. Not quite what we had in mind.

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://123.123.123.123 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.

Category:
Notes
Tags:

Join the conversation! 26 Comments

  1. What’s your take on cloning tools such as the one ManageWP has? I haven’t noticed anything adverse.

  2. Why all of those steps? Why not just download all of the files (instead of just certain diretories), push them up to the new server, and move the database over?

    You move the entire db anyhow, so I don’t understand why you do a separate WP install, and move certain directories and all of that. Just move it all and be done. Or am I missing something?

    • In my experience, doing a full blown migration of a site by doing a mass upload something always gets lost.

      I’d rather do it in stages where I first install the WordPress application on top of a fresh database, then slowly bring things over.

      Whenever I’ve tried to do things in huge chunks, there are a number of points of failure that can happen (and they have happened) and then it’s tough to diagnose or have to start over because I can’t find exactly where the problem exists.

      And, honestly, I tend to be a bit more compulsive where I like to basically:

      • Divide and conquer
      • Complete each stage, verify, then move to the next

      I’m certainly not saying my way is right or even the best way, but it’s one way that’s proven to provide me with me most success in a lot of the work I’ve done.

      And I’m sure you way has worked fine, too :) so this certainly isn’t to disqualify that! Ultimately, whatever works best for you (be it your process, my process, Backup Buddy, or some other software) is all good for me.

      • Cool, that makes sense. There are certainly a lot of ways to get it done, most of which will be successful. :)

      • Great, I had the same question as Mickey-your answer make sense. Doing a migration as you said will definitely reduce the risk of something getting screwed up…and I have heard horror stories about sites going down during a “one click” migration.

        • My whole goal is to break the migration into individual steps or points so that I’m mitigating the potential for failure.

          “One-clicks” have n-number of failure points where if I break them into steps, there’s only so many things that can go wrong with, say, importing SQL, you know?

  3. I’ll share quick tip on how you can verify that the site is working 100% in the new environment BEFORE switching over DNS (or just before your DNS changes kick in).

    Add a line to your computer’s hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on Linux and perhaps Mac too) to force your computer to resolve the site’s domain to the IP address of your new server.

    The new line should look something like this:

    123.123.123.123 yourdomain.com

    (of course replace the 123.123.123.123 with the actual IP address and yourdomain.com with your domain)

    After you’re done testing you should probably remove this line so you can see what the rest of the world sees in terms of where your website lives.

    • Yes sir – fantastic tip. Thanks for sharing this!

    • Killer Tip!

    • For the record, it’s /etc/hosts on UNIX-based systems and that’s how I do migrations too – move the entire WP folder + the SQL dump to the new server, point my domain locally to the new IP, import the database, configure wp-config.php with the new DB data and voila – everything is working.

      I have all the time in the world to test the new server data before setting the new name servers. I usually change an admin option while working to make sure current DNS is resolving the new server (even though I can just ping the domain and verify the IP returned).

  4. I used to do it manually until I tried Duplicator

    It’s a great tool, I’ve done lots of transfers from local to live sites and live to local to test upgrades and it hasn’t failed me yet.

  5. Having been through the process myself recently. I took the back-up from the previous night plus the database (having created a new blank one) uploaded them and then tweaked everything. Of course, I also had extra back-ups of images and so on on my PC just in case. Took me about ten minutes in all….

  6. Thanks for sharing this. It’s always fascinating to get a look at how other devs do things. Breaking the process down into a manageable system makes a lot of sense, versus dumping in the whole load of laundry. Some hosts like WP Engine help make this process easier than others as well.

  7. I’ve found using SSH to be a super awesome (and fast) way to move all those uploads, etc…

    Here’s how I do it: http://churchm.ag/migrate-your-website-with-ssh/

  8. Out of curiosity, what hosting services did you move from and what did you move to?

    • I switched from Site5 to a Media Temple (dv) 4.0 server.

      To be clear, I’ve nothing nothing against the guys at Site5 – I still host several sites there, and will continue to recommend ’em to people based on their needs.

      But this blog had outgrown the server it was on so I moved to the (dv).

  9. Thanks you for the share!
    Can I use plugins to do this to migrated the wordpress database.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.