Moving and Upgrading Your WordPress Weblog: A 20-Point Checklist

This post is the second in a loose series about moving weblogs. Having just finished a “big” WordPress weblog move that I’d been dreading for close to a year, I wanted to share some of the process and parameters with you.

My flagship tech site has been around for just over two years. It started off as a replacement to a site I had started in 1999 and was only static pages until about April 2006. At that time, I added a blog. But WordPress was only at v 1.5.2 at the time, and I was moving away from my Blogspot blogs. So the site had several types of content:

1. An old static set of pages and directories that still get traffic and originally ranked at PR6 before Google changed their algorithm in late 2006.
2. Nearly five blogs created in Blogger but physically hosted on my domain.
3. The primary blog.
4. Lots of additional directories and content from client projects.

I could not lose any of it.  What’s more, I had nearly 1200 emails to save from a horrible email interface and didn’t have all the mail server details handy. (Not blaming him, but my brother had set everything up on his hosting account in Mar 2005, and I didn’t bother getting all the details until now.)

Needless to say, I’d been dreading this move. I didn’t want to stay with WordPress 1.5.2. I also don’t like the new WP 2.2, which has gotten rid of the preview area in the editor page, and has some strange quirks regarding draft-mode articles. But I had to weigh a number of factors, including the fact that the site couldn’t be down for long, and that my time is limited.

Now, there are many types of “moves” that can be performed for a weblog. This one not only involves changing hosts but also upgrading the blog platform version. And it all has to be done at the same time. My research into upgrading from WP 1.5.2 to 2.0.x suggested that it’s not a problem-free switch. I assume that’s true for moving to WP 2.2. Being a tech geek, I opted for a “brute force” process. On the off chance that it’ll help someone, here it is below. Much of it is still applicable to many types of WordPress to WordPress blog moves.

1. Backup all files via FTP.
2. Backup all database files in .sql format. Because of having a giant database, I did this on a table-by-table basis, not for the entire database all at once. It takes longer, but it saves me having to try opening a 229 Mb backup and crashing my computer everytime I strike a key. [Note: WordPress and/or Spam Karma stupidly save the contents of spam comments, instead of just the IP address and date.]
3. Make a list of all the plugins being used in the old installation.
4. Configure Outlook Express (or your fave desktop email client) to access the domain’s email account.
5. Download all the email messages to my computer.
6. Buy new hosting. My old hosting was with morons. Hands down worst, most non-upgradeable host I’ve ever worked with.
7. Set up the new hosting account, but don’t change the nameservers just yet. At this point, you’re only working with the new server’s IP address.
8. Install the latest WordPress. Most hosts now offer “one click” WordPress installation in one to three clicks. If not, you’ll need to download the latest version from WordPress, then upload to the new IP address using an FTP program such as Filezilla.
9. FTP upload all the directories for the old static site.
10. FTP upload all the files and directories for the self-hosted Blogger blogs.
11. FTP upload the themes and plugins from the old WordPress installation.
12. Port the old database content into the new installation. Please see below for an explanation.
13. Change the nameservers for the domain at your registrar, to point to the new hosting.
14. Wait a few hours for the nameservers to change. (Note, it can take up to 72 hours for the changes to propagate across the Internet, so do not ditch your old hosting right away.)
15. Reactivate all the plugins. Make sure that your old plugins will work on a new version of WP.
16. Test a few pages for various sites hosted on the domain.
17. Create the new version of the email account.
18. [optional] Reconfigure Outlook Express for the new hosting’s mail server. You’ll retain your old email messages and be able to
19. Send a test email message from elsewhere. (You could also configure your GMail or new Yahoo! Mail account to manage this email account. I use GMail to manage my Yahoo email.) Note: It’s possible that you could be losing some of your email during the server changeover, but there’s little you can do about this. Fortunately for me, this is one of those accounts I use mostly for receiving newsletters and account updates.
20. Drop the old hosting plan.

Now to expand upon the really hairy database porting process. I don’t recommend you do this unless you are incredibly patient, have a block of time to dedicate without distraction, and are unafraid of a mySQL database admin panel or two. Get someone else to do it for you.

Note: My old host had the database admin URL as part of my domain instead of a separate server. While I usually prefer splitting off the database from the blog installation, I decided to stay with the same sort of set up. Part of the reason is that some hosts don’t actually allow you to configure the new installation unless you’ve already changed the nameservers. That means your site will be down until you’re done, and visitors may see partial content while you’re working on the upgrade. There are ways around this, but my time was limited and I didn’t want to monkey around too much.

1. Open up the old hosting’s database admin panel.
2. Open up the new host’s database admin panel.
3. For each table in the new database:
   1. Empty the database.
   2. Open the .sql backup from the old installation.
   3. Copy only the “Insert” records over to the new database’s panel and perform a SQL operation.
   4. A few things to consider:
      1. Check to make sure the correct number of records were imported.
      2. Your old installation may have had a custom prefix in the name of a table. For example, I had “wp_tb_” in front of each table, but the new installation only had “wp_”. So using a text editor, I did a mass replace of that string.
      3. Make absolutely sure you don’t copy the “create table” portion from the backup .sql files. Unless you are not changing WordPress versions, you do not want to obliterate the new tables.
      4. Some of WordPress 2.2’s database tables have a different structure than 1.5.2. This meant I had to spend time manually changing each INSERT record before applying it on the new installation. A text editor with “search and replace” functionality helps an awful lot. If I didn’t have that, it might have taken me half a day just to make the INSERT record changes – and that for a blog with only about 160 posts.
      5. Some tables in WP 1.5.2 don’t exist in WP 2.2.
      6. Some content, such as WordPress “pages” may not import into the database when applying the INSERT records. I had to manually rebuild my “pages”. Only the “posts” (aka permalinks) imported properly.
   5. Proceed with caution at each step. Better safe than sorry.
4. Double check, or for the obsessive compulsives like me, triple-check the number of rows.
5. If you are changing the your WordPress permalink structure, use Dean Lee’s permalink migration plugin. (Thanks to ifranky for that tip.) That’s left as an exercise to you. I won’t get into to the process at this time.

Did I miss anything? Looking at this entire process, it is intimidating and not recommended for everyone. If you have any questions or alternate steps, please feel free to comment.