There are plenty of different ways to do a WP migration and a google search will yield plenty of advice. You can find a number of plugins (such as a backup plugin like UpdraftPlus or Backup Buddy) to automate a migration process. If you do it manually you can always refer to the exhaustive WP codex instructions. I much prefer to manually export the WP site’s mySQL file from phpMyAdmin, then use a cPanel app to download the entire public_html directory. I always move an existing site to my development server and make changes there before making anything live. Downloading Peggy’s site took about 1/2 hour, even with a pretty speedy Comcast Business Class connection. And her WordPress SQL Database file was over 100mb!
An SQL file is really just a simple text file. I’ve found that separating the ‘wp_posts‘ table (which also contains all of the media links) from the rest of the database and running a global change using something like Notepad2 or another elevated code editor is a quick and easy way to make the needed changes to move a WP installation. Is this case, the global change was just a simple “find & replace” operation, changing “http://www.eugenephotographer.com/blog” to “http://www.eugenephotographer.com” (Of course, the ‘siteurl‘, ‘home‘ and, usually, the ‘upload_path‘ entries in ‘wp_options‘ also need to be updated.) In some cases, a special table used by a plugin will also need to be updated but, for most sites, those are the only changes that need to be done — getting around the file size limit of her web host.
The trick with Peggy’s site was that was so large. She’s very good about updating her website with new photos and blog posts. But that meant that, with regular posts to her blog since 2008, her ‘wp_posts’ table alone was larger than the maximum allowable size to import into her webhost’s phpMyAdmin server. Although I’d never needed to use it before, there is a handy setting in the export screen of phpMyAdmin which allowed me to set the number of records to download to half of the total number of records so that I could easily split the ‘wp_options’ table in two. Then it was simply a matter of uploading the file in two operations instead of one.
In the image above, you can see there were 8220 records. Changing that number to 4110 allowed me to export half the records. Then, in a second export, I changed the ‘starting at record #’ to 4111 and exported the second half. Importing them into her webhost’s server in two chunks let me get around the phpMyAdmin upload limit.
When it came time to move the new site back to her web host and into her home directory, I opted to just move/copy her ‘/uploads/’ directory from the existing WP ‘/blog/’ sub-directory (that was already on the webhost) into the new WP directory structure and only actually upload the current month’s upload directory from the development site, which contained some new images for her new website. It ended up saving quite a bit of upload time.
Once those the size hurdles were handled, her site fell back into place very smoothly. Of course, there are other significant considerations to be considered, such as creating 301 redirects from the HTML pages and the old /blog/’ sub-directory, as well as the impact on the site’s SEO presence. However, this post is just intended to be a few notes about the nuts & bolts of the WordPress migration. Every site can present a unique set of interesting challenges!
Visit Eugene Photographer to see how it came through the migration! Her portrait photos are truly amazing and she is an absolute joy to work with — I might even let her take my picture some time.