Moving Day: A Guide for Moving One WordPress Site to Another

55 Comments

Moving Day post graphic

One of the best parts of WordPress is just how easy it is, not only to import content in from other content management systems, but to export and take all of your content with you out of WordPress itself. There isn’t the feeling, like with so many systems and web apps out there, that you are deliberately being locked down into using one particular system. And like anything, there is an art to moving your WordPress site from one location to another.

Why move?

There could be any number of reasons for moving your site to a new location. Perhaps you are changing hosting providers (as we all do at one point or another) and are moving all of your stuff someplace new. Most of the time, for me, it’s because I’m setting up a client’s site based on a local or remote testing installation.

A better question would probably be: why test? More often that not you will be moving a WordPress site to a new location because you first had it in place, testing it. And this is only smart. Live testing, where people know how to find it, is never smart. Testing it in secret can help you foresee and diagnose many of the potential problems, and help you save face once you turn it live.

In the 100 or so odd times I’ve moved a WordPress site from one location to another, I’ve casually put together a mental checklist that I go through to make sure I hit all of the points I need to, and to speed the process up. Consider this a mental brain dump, for your benefit.

First things first: handle your content

The most important part of your site, you’ll want to move over your content first. When I say content, of course, I’m talking about a couple of different things. Most obviously it’s your database export. You can grab the XML file of that content at Tools > Export. This is pretty straightforward, and shouldn’t really confuse you.

If you are moving from one remote host location to another, then moving content is pretty simple. In your new WordPress installation, go to Tools > Import and select the file you just exported from your other site. Be sure to check the box that will download and import all of the files from the other site you’re moving from. This will grab any images/files you uploaded and reconstruct the uploads folder appropriately.

If you’re moving from a local WordPress site to a remote one (let’s say you’ve been testing locally, for instance) then this process is a little bit more difficult. You can’t actually trust WordPress to find and import all of your files, since your site is hosted locally, and WordPress won’t look on your computer. So in this case you’re going to have to grab your wp-content/uploads folder manually, and move it over.

The easiest way to make sure all of the files are linked up correctly throughout your site is to use a nifty Plugin called Search and Replace. It will run through all of your content — pages, posts, everything — and replace any string with another string. So, have it replace your original site’s URL (only the beginning, before the /wp-content part starts) with your new one. This should cover your bases pretty well.

Move over relevant Plugins

Now turn your gaze to your wp-content/plugins folder. One of the reasons I like testing before pushing a WordPress site live is that I often go through a couple of Plugin options when solving simple problems. Odds are that I’ll have a number of Plugin choices that I didn’t use lying around, cluttering things up. So when I push everything to its live location, I’ll only take the Plugins I’m actually using. I suggest you do the same thing.

Match relevant settings

You’ll want to make sure that your settings are the same between your two installs as well. The easiest way to do this is just to open up two tabs and run through all of the screens within your Settings tab of the Dashboard and make sure everything is the same. Depending on the number of Plugins you normally run, this may be a fairly large endeavor.

A couple of things I always watch out for:

  • Be sure that the home page and blog page are set correctly on the Settings > Reading page.
  • Check that your comment settings (in Settings > Discussion) are set the same, specifically the number of threaded comments you’re allowing.
  • Set your permalinks (Settings > Permalinks) to be what you had them before. Otherwise, any linking you did within your site will likely be screwed up, even using the Search and Replace Plugin.

Note: If you do happen to change your Permalinks structure, use a Plugin like Redirection to send URLs to their new locations.

What do you do when moving your sites?

Every site move brings its own problems and frustrations. Odds are you’ve discovered your own methods for making this a painless process, and that you’ve come across some ideas that I haven’t. Speak up in the comments.

55 thoughts on “Moving Day: A Guide for Moving One WordPress Site to Another

    • That’s definitely a possibility, sure. But, as I’m sure you know, for most users the best instructions to provide is not to tell them to start poking around in their MySQL. It’s a technique that advanced users will use, for sure, but then again this isn’t really aimed at advanced users.

  1. I recommend the mysql route too. Often things get missed in the WordPress export that you might not expect. I recently moved a site that had 80 Link Categories and nearing 500 Links in the Links section (blogroll). Guess what – none of that is included in the WXR export. Yes, there is a plugin which can handle import/export specific to the blogroll stuff – but the point is that MySQL export gets all that stuff.

    Further – the non-advanced users might also miss out on data set up for them by other developers – data that might include custom DB tables or fields not in the WPCustom entries… just sayin’ :)

  2. The way I do it:
    1) Use mysqldump to dump the WP database (safer than phpMyAdmin which sometimes screws-up character encoding)
    2) Use SCP or SFTP to move WP directory and database to new server
    3) Import database from shell
    4) Make adjustments to the WP config file

  3. I agree with Ryan – if I ever have to move a site I download the SQL file, find/replace the URL (sometimes returns 100s of instances), and then import into the new site. More often than not, there are tons of plugins installed on the site and trying to match settings would take all day.

    However, for the typical WordPress user, this is a great guide to moving your site. Thanks for the post, Ryan!

  4. Ive used both methods. Normally I prefer the Tools Export setting as this takes care of most items. There are a few plugins that may require you to use the my sql method, but I have had to move from our test servers to a clients host servers before and the sql export method (because I did not have domain access to wp-admin yet) was used and different providers often use different prefixes for the sql field names and this can cause a lengthy transfer process.

    It is definitely good to know how to do both but the simpler the transfer can be the better for most users.

  5. Thanks very much for this post.

    This subject is just what I’ve been looking for.

    It is really helpful to me ( the one who doesn’t know much technical thing.
    and the wordpress codex is not really easy to follow as it’s written by
    those who know things – which tends to write in NOT easy to understand format.)

    And I will be very very happy if the mysql method is also provided
    ( maybe in the future post. ) as it’s good to know different ways of doing thing.

    This kind of tutorial is really helping people like me to learn.

    Thanks again.

  6. I prefer the MySQL method, but it’s not without problems. Depending on the hosting environment the SQL export may or may not import. It’s usually a permissions issue, but worth thinking about before trying a database dump.

    However, I agree that a dump is the best way to grab everything. 9 times out of 10 it’s the method I run with.

    Ryan, thanks for the post!

  7. Pingback: Wednesday Web Candy – 9/2/09

  8. I found often times that the mix of hard-coded and relative weblinks through a wrench in some posts. I’ve since decided to use the Maintenance plugin to show a “We’re coming soon” jpg, while I work in the backscenes, with a hard-to-guess password. It helps that I usually provide web hosting to my clients, so they can’t run away with the code…

  9. I think Ryan is on the right path talking about a more consumer friendly approach to import/export. It’s about empowering the user to do this themselves. The only real drawback I have found with using the built in wp import/export is when moving hosts but going samedomain to samedomain.

    Example: When they export the wp file, and then change the dns to point to new servers and do the import, all the data moves fine but when it attempts to grab the linked media it of course fails as it is attempting to access links that now point to the new server where the images do not exist.

    One method of course is to ftp the wp-content folder over. One could also use a wp.com blog as a staging service. Not sure wp.com would appreciate that though.

    Again, I think it is all about empowering the user and not forcing them to understand mysql.

    This is an issue important to our customers at http://page.ly, so finding the shortest path for migration is on our priority list.

  10. Moving your WordPress site can be a really scary thing to do (especially if it is a clients site, and we all know how much they like their sites being down).

    this is a nice little guide. Thank you.

  11. Another thing to keep in mind is that with a little basic understanding of the exported data, you can always edit the exported XML file before you import it into your other WordPress instance.

    Our client had us move the WordPress for http://www.ourgreendirectory.com from the public instance to an installed instance on the web site. The problem was that the client kept making his updates to the older version until we got him to use the correct wordpress url.

    We exported the Public WordPress instance – edited the xml file and then imported the edited xml file into the web site based wordpress instance.

    It is not a simple editing process but it is possible.

    We actually missed the duplicated categories so we just had to delete the unassigned duplicate WordPress categories after the import.

    This is a great service that WordPress provides and I personally think it is a great reflection on the understanding that WordPress has of customer service and why they blog/cms solution is so widely used.

  12. Both methods are good for sure, but for someone doing it for the very first time, many things can go wrong with mysql…so I think it’s a nice and especially foolproof way Ryan described.

  13. Because you already took inventory, look at the list and decide the value of your processions. Consider getting comprehensive insurance through your moving company. Insurance will protect the value of all your belongings.

  14. Sometime I have found the tools export in WordPress has caused problems with linking when moving a site, the best method I have found is to export and import the database through phpmyadmin – here is how to do that http://codex.wordpress.org/Backing_Up_Your_Database
    Then follow the info here on updating links through phpmyadmin http://www.mydigitallife.info/2007/10/01/how-to-move-wordpress-blog-to-new-domain-or-location/ . Always works like a charm. You just need to make sure you move your uploads, themes and plugin files over via ftp.

    Like Dan said, this keeps all the plugin settings so no need to go and re-enter all those.

  15. Pingback: A Guide for Moving One WordPress Site to Another | Start the Loop

  16. I have a reason why you’d use the import export method over MySQL. I’ve moved servers a few times as the site has outgrown the resources and along the way the WordPress install has gotten a little buggered up. So I’m about to try the import export method with a fresh WP install on the new server to kinda start from scratch but with our content intact.
    MySQL and ftp dunp is faster for sure, but any issues you had with the previous install are coming with with those methods…
    Good to know both methods.

  17. The last time I moved a big WP install (with Tools > Export and Tools > Import) it moved all the posts but detached the attachments’ connection to the post. So I had to go back and re-upload images for each post since the theme I had custom built used the first image attachment as the thumbnail on the index, search and archive pages. It was a nightmare! The MySQL move would have prevented that but I needed a quick option without bothering the sysadmin that day.

      • Ryan, friends,
        All attachments did indeed import using the WordPress xml import option. BUT all attachments became detached. How would I go about reattaching the images.

        215 posts

        794 unattached images

        Any suggestions about how to fix this headache?
        Looking… looking…

        Arghhh… ;-)

        • Partial Solution:
          1. Reinstall or drop all the data from MySQL database
          2. Import monthly xml export files
          3. It is helpful to know you can refresh during the import if for one reason or another, the uploaded file times out. WordPress recognizes if posts and content has already been imported.
          4. Month by month imports actually made the transfer successfully on this media heavy blog. A single 4.2MB import file and associated media was not the way to go.

          In the end, I have most of the Media imported attached to posts. Still not perfect, but better than otherwise…

          Anyone else run into this problem and find a fix?

          • This also happened to me (even after breaking down the export by month).

            With the wordpress-importer plug-in activated, I added these lines of code after line 1106 “if ( $post_exists && get_post_type( $post_exists ) == $post['post_type'] ) {” in wordpress-imported.php file in the /wp-content/plugins/wordpress-importer directory:

            $post_parent = intval($post['post_parent']);
            if (is_numeric($post_parent) && is_numeric(intval($post['post_id']))) {
            $my_post = array();
            $my_post['ID'] = intval($post['post_id']);
            $my_post['post_parent'] = $post_parent;
            wp_update_post( $my_post );
            }

            This basically sets any existing file to the parent it is specified in the XML file.

            Hope this helps!

  18. This tutorial is just what I’ve been looking for!!!! Thank you so much for taking the time to write such a helpful tutorial! :)

  19. Pingback: A Better Way Of Managing Your Author Website

Leave a Reply

Please note that WPCandy is a moderated community.

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>