Possible Duplicate:
Easily Move a WordPress Install from Development to Production?

So I've been working with WordPress for a while now and I usually develop locally and then upload everything to my Prod server... however, I've experienced a lot of differing results, especially when using plugins.

I usually export the database, but things like the location of the domain don't always seem to get changed even after changing them within the WP admin beforehand.

What's the best way to move from Dev to Prod and keeping everything intact?

Then, what's the best way to move your site from a subdirectory on the same domain?

Please don't point me in the direction of the WP docs... it's the first place I looked.


6 Answers 6


Any difference between dev and prod is bad. Here is what I do:

  • Have a different ip for dev server (Whether internal, external, or on local computer is unimportant) -- but dev server must be the exact same setup (see bottom paragraph)
  • Change the hosts file (see here) (on yours or a testing computer or a virtual machine) to point to dev server ip
  • Result: HTTP requests sent to dev server have Host header field set as "example.com" exactly like it will be for the prod server.

This method removes two differences often encountered otherwise:

  1. having to change domain name
  2. having dev code in a subdirectory, but prod code in root or diff subdirectory. This is because I use git to transfer files between dev and prod.



The dev server is set up exactly the same as the prod server (see Chef or Puppet for how to programmatically manage servers).


In my experience, I've used the Search and Replace plugin to re-reference all of the references to the old domain. Not the cleanest solution, but seems to work.


I do the same dev-prod kind of deployment on a regular basis, so I developed some standard queries for it:

  1. Update the site url:

    UPDATE wp_options SET option_value = replace(option_value, '[DEV_URL]', '[PROD_URL]') WHERE option_name = 'home' OR option_name = 'siteurl' OR option_name = 'fileupload_url';

  2. Update the upload path:

    UPDATE wp_options SET option_value = '[SITE_ROOT_PATH]/wp-content/uploads' WHERE option_name = 'upload_path';

  3. Update the post guids:

    UPDATE wp_posts SET guid = replace(guid, '[DEV_URL]', '[PROD_URL]');

  4. Update urls in posts:

    UPDATE wp_posts SET post_content = replace(post_content, '[DEV_URL]', '[PROD_URL]');

Replace the bracketed variables with actual values eg.

[DEV_URL] -> http://example-local-pc.com [PROD_URL] -> http://example-online-server.com [SITE_ROOT_PATH] -> /home/client/domains/example-online-server.com/html

That typically takes care of any references to the dev environment. You should note, however, that:

i) Many plugins also store absolute urls either in wp_options or custom tables. These you have to investigate on a case by case basis.

ii) Running an update replacement query (such as 1. and 2. above) shall almost certainly corrupt data in serialized fields. I haven't come across a clean and fast technique yet of doing this replacement other than letting the associated plugins do the update themselves. The success of this depends on the robustness of the plugin.

  • As for as I know you should never change the GUID, they are permanent global unique identifiers, doing so will mess up the feeds.
    – Wyck
    Nov 18, 2011 at 23:36
  • The reason I do it is the fact that the locally referenced GUIDs aren't going to make sense online. If you take a look at the posts table you'll realize that infact they are urls to the posts. Doesn't that make it more accurate to have them match the actual production urls for the posts?
    – KalenGi
    Nov 18, 2011 at 23:57
  • No, that not how it works, they are just unique identifiers, not actual urls used for anything, it just a silly way wordpress stores things:/ If you change them, your feeds will get all messed up because they cannot reference the identifier, so you might send out duplicate feeds and so on.
    – Wyck
    Nov 19, 2011 at 0:03
  • Yes, it's true that they are for uniquely identifying the posts. So if you are migrating from one online domain to another then it's not advisable to make the alteration. However, I doubt there's much harm done when moving from a local dev environment to an online production server. I just find it cleaner to remove any traces of the dev environment.
    – KalenGi
    Nov 19, 2011 at 0:27
  • Very true, I for some reason thought of a staging server or moving site urls.
    – Wyck
    Nov 19, 2011 at 1:13

I like to develop on a sub-directory so I can let my clients have access to the test site. when I'm ready to publish I use a plugin (recomendations below) to duplicate the whole thing to another sub-directory and then just point WordPress to load from the new one. Leaving the dev area active for testing.

Use a plugin like duplicator (free) or backupbuddy (paid). Also see if my question here helps you.


There is no flawless way due to how WordPress stores content in the database.

For pushing code around it can be as flawless as using git/mercurial/svn or even just file over-writes.

But that is not the case for any content stored in the database (plugins, posts, categories, etc) and there is no good way to sync two databases. How to: Easily Move a WordPress Install from Development to Production?


I use this search replace tool:


It works for other software as well as wordpress.

As for deploying, I set up an environment on the server which I can then switch via domain mapping/vhosts to make live. The install Dev is always on a separate server, and is never made live.

Not the answer you're looking for? Browse other questions tagged or ask your own question.