We would like to push our Drupal development environment to production. We have CiviCRM integrated. Obviously our production Civi data has changed since we created Dev (Drupal+Civi).

Is there any documentation explaining best practices for pushing out Drupal updates from a development environment to production without affecting CiviCRM's current db?


1 Answer 1


Generally, CiviCRM's data is stored in separate tables and you can treat the CRM and CMS as separate entities.

Many people store the CRM and CMS in separate databases for convenience (eg exampleorg_drupal & exampleorg_civicrm).

Particular items to check, though:

  • If you are using Webform CiviCRM or CiviCRM Entity, you may need to rebuild connections between referenced CiviCRM entities (eg contribution pages, contacts, ...)
  • You may want to check your civicrm_uf_match tables for mismatches. This maps Drupal users to CiviCRM contacts, so changes on either side, eg users added on the old Drupal DB might trigger an incorrect match to a Drupal user in the new Drupal DB.

Once the transition is complete, you may need to give some well-placed kicks to get things running smoothly. These may include -

  • Clearing Drupal and CiviCRM caches.
  • Deleting the contents of CiviCRM's templates_c directory.
  • Rebuilding Drupal's registry (drush rr)
  • Correcting/deleting the Drupal variable civicrm_class_loader

If a CiviCRM install permits any anonymous input (including recording user actions like CiviMail opens, contributions or profile submits), working at the whole-DB level can mean choosing between downtime (disabling the site while you make changes) and potential data loss (losing data while you switch between a minutes-old backup and the current DB).

For that reason you might want to look into practices that let you deploy change in smaller parts, since that means you can integrate updates will reduced risk at each step. There is more established practice of this on the Drupal side, with tools like Features, WFTools, and (in D8) Configuration Management.

  • 1
    Great answer. I do what you're describing relatively frequently, and it's a symptom of the relatively loose coupling between CiviCRM and it's CMS. It works particularly well if the changes to Drupal are not too radical, but I've just done this for a couple of Drupal 6 to Drupal 7 migrations and it all worked fine. Re: the civicrm_uf_match issue - just truncate that table and then rebuild from the CiviCRM interface. But it is very important to do this.
    – Alan Dixon
    Oct 19, 2015 at 13:45

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.