The migration is from the local environment to the production environment. The production environment has run some time and created a lot of articles.

In order to add new things to my site, I added a custom theme and installed CCK, Views and other modules in my local test environment. Now that the local test environment is finished, how do I migrate it to the production environment, without destroying the content of its database?

3 Answers 3


This is a non-trivial problem that almost everyone has a different answer for: there isn't a canonical Drupal way to handle staging to production pushes. Dries Buytaert, the guy who runs the Drupal show, made it one of the key initiatives of Drupal 8. Of course, Drupal 7 was just released, so it'll be a while before that bears any fruit.

The problem can be broken out into two separate issues:

  • Staging configuration (variables, content types, fields, views, etc.)
  • Staging content (nodes, users, etc.)

The former can be mostly handled by the Features module, which will take your site configuration and turn it into a module you can add to your Drupal installation: this way, you can add it to your version control system and not having to worry about it being blown away when you migrate your content.

The latter is really tricky, because on an active site, it's likely the content will change on production even after you've made the initial sync to your development environment. This prevents wholesale replacement of content during staging like you can do with configuration.

Additionally, Drupal doesn't use universally unique identifiers (UUIDs) for content: every time a node or a user is added, the ID increases by one. So what might be node 45 on your development site might be node 90 on your production site.

Unfortunately, I don't have a great solution for this: staging content is a real weakness of Drupal. What I personally do is add content on the production site only. If a client wants to see how the content looks prior to it going live, I'll set up a clone of the production site that's only accessible to the client. Then, once approved, the same changes are then made directly to production.

There's another alternative that gets tossed around: the Deploy module. It's supposed to leverage Services to make staging content relatively painless. But I can't vouch for its effectiveness and it doesn't have a Drupal 7 version.

  • You can migrate content using uuid and uuid_features, but it is not that reliable yet. Commented Apr 15, 2011 at 9:12

In our process.

  1. We have a shell script that pull the db from prod.
  2. We are using Hudson to rebuild our dev/staging branches to sync live and dev branches.

    Since we are using Git, every task we are doing has its own branch, then when passed to QA we merge it to master as our staging server for regression testing.

    When master is ready we do a test release to our Release Server which is a replica of live (configuration, hardware, etc).

  3. We use Feature module to deploy configurations. Some stuffs are not yet supported by feature so we use hook_update_N then run updatedb.php or drush -vd updb

  4. After release perform Features revert(drush fra --yes) to revert all overriden feature.
  5. Since we are using Boost(moving to Varnish) and Memcache, we need to clear the cache(drush cc all).

    We are using rsync to sync our images/video etc...

  • Can you please elaborate step 2 - Using Git I understand that we can merge any file system changes easily, but how do you ensure the integrity of database? Also, what exactly is the purpose of using "Features" (to deploy configurations) here? Thank you! Commented Apr 7, 2015 at 9:21

To Migrate from a XAMPP server to another server, I followed the instructions on this site.

Make sure that you keep the same structure on your production server as you did on your development server. I also had to edit some files in Drupal admin dashboard located at: admin/config/media/file-system

Ensure that your Public file system path and Temporary directory have the correct locations set.

  • This never talks about the "merging" problem. The question clearly states that production has content data which has to be intact while enhancements from staging server has to be merged in production. Commented Apr 7, 2015 at 9:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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