If you’re a WordPress developer, migrating a finished development project can be one of the trickiest parts. There’s moving parts in many places that have to be taken into consideration, and migration is (unfortunately) where WordPress actually could use some improvement. However, it’s a necessary evil – one that I’ve done almost daily for a few years now. I’ve developed a nice system to move everything over in one fell swoop, and the majority of the work is done by the WP-Migrate-DB plugin.

FYI: There is a Pro version of the plugin, but for my purposes I haven’t needed it – this will all be done with the basic, free version you can download in the plugin repository.

Step 0: Theme Preparation.

Most people, when running a migration, always seem to get stuck when they start analyzing their theme files. Novice developers will hard-code their links instead of using template tags, which means when the site is migrated everything ceases to run properly. The best way to do this: use…

<?php echo home_url(); ?>

…which will automatically parse out your URL. If you’re linking to something in your theme folder, use…

<?php echo get_stylesheet_directory_uri(); ?>

…which links to your theme’s folder. A sample usage:

<img src="<?php echo get_stylesheet_directory_uri(); ?>/images/logo.png" />

Step 1: Which Files Should Go Over?

Any good WordPress developer will tell you: never, ever, ever make any changes to the WordPress Core. And that’s for a good reason: the WordPress Core will always be the same, no matter what install you use. Since that’s the case, it’s easy to deduce that only the ‘wp-content’ folder, which houses your themes, plugins, and uploads, will be different between WordPress installations. Zip up your wp-content folder – it’ll shave off a few megabytes when you need to transfer everything over.

Step 2: Start with a clean WordPress install.

It’s not completely necessary, but I do enjoy unzipping and installing WordPress from scratch. If you’re creating a new site, fantastic – simply run your normal install process. This ensures you’re starting from a clean slate. If you’re replacing a currently existing site, it’s a little harder, but not much. You’ll wait a bit to install WordPress.

Step 3: Run WP-Migrate-DB on your Dev Site.

Install WP-Migrate-DB. When you do, you’ll come to a screen with a bevy of text boxes.

I’ve filled out this sample with an example site migration (one I’ve done in the past!). There’s a source and destination area. The source is where you’re migrating FROM; the destination, TO. Simply fill in the source and destination URLs. The file path helps with accessing files through plugins and what-not. Usually it’ll be something like ‘/home/username’ or ‘/var/www/html/’ or ‘/public_html/’ – it’s specific to your hosting environment. The source is usually filled out beforehand – you just need to find the destination.

In my opinion, it’s a good idea to replace the GUIDs, only because we’re launching a new site. This helps everything to be incrementally set, and just makes for an overall better back-end experience. Also, there may not be any, but in case there are I’d not bring over post revisions and spam comments – might as well start fresh and clean!

You’ll get a SQL file downloaded to your computer. Hold on to that file.

Step 4: The Actual Migration

Here’s the remaining steps – they should all done within a few minutes of one another:

Install WordPress, if you haven’t yet.

Unzip the ‘wp-content’ folder.

Drop the database contents and import your migration dump.

Step 5: That’s It!

The site should function exactly as it did before – all of the strings are serialized, which means none of the weirdness that comes with a typical database dump will happen (usually). Personally, I like this idea because it eliminates a step in my typical process – I usually grab a backup of everything as I launch anyway, and this just lets me kill two birds with one stone.

Let me know if this works for you – and go and migrate your heart out!