Answers.Body: <p>Generally, CiviCRM's data is stored in separate tables and you can treat the CRM and CMS as separate entities.</p>
  
  <p>Many people store the CRM and CMS in separate databases for convenience (eg <em>exampleorg_drupal</em> &amp; <em>exampleorg_civicrm</em>).</p>
  
  <p>Particular items to check, though:</p>
  
  <ul>
  <li>If you are using Webform CiviCRM or CiviCRM Entity, you may need to rebuild connections between referenced CiviCRM entities (eg contribution pages, contacts, ...)</li>
  <li>You may want to check your <code>civicrm_uf_match</code> 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.</li>
  </ul>
  
  <p>Once the transition is complete, you may need to give some well-placed kicks to get things running smoothly. These may include -</p>
  
  <ul>
  <li>Clearing Drupal and CiviCRM caches.</li>
  <li>Deleting the contents of CiviCRM's <code>templates_c</code> directory.</li>
  <li>Rebuilding Drupal's registry (<a href="https://www.drupal.org/project/registry_rebuild"><code>drush rr</code></a>)</li>
  <li>Correcting/deleting the Drupal variable <code>civicrm_class_loader</code></li>
  </ul>
  
  <hr>
  
  <p>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).</p>
  
  <p>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 <a href="https://drupal.org/project/features">Features</a>, <a href="https://github.com/wftools/wf">WFTools</a>, and (in D8) <a href="https://www.drupal.org/documentation/administer/config">Configuration Management</a>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-19T13:45:47.913Z
Answers.Text: 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.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-18T19:37:45.827Z
Answers.LastActivityDate: 2015-10-18T19:37:45.827Z
Answers.UserDisplayName: Chris Burgess
Body: <p>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). </p>
  
  <p>Is there any documentation explaining best practices for pushing out Drupal updates from a development environment to production without affecting CiviCRM's current db?</p>
  
  <p>Thanks</p>
  
Tags: <drupal><best-practice><deployment>
Title: What impact may deploying a changed Drupal DB have on CiviCRM?
ThreadText: # What impact may deploying a changed Drupal DB have on CiviCRM?
  
  (Asked by: username_0 on 2015-10-17)
  
  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?
  
  Thanks
  
  **Tags:** drupal, best-practice, deployment
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-10-18. Score: 7 | Accepted answer
  
  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`](https://www.drupal.org/project/registry_rebuild))
  * 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](https://drupal.org/project/features), [WFTools](https://github.com/wftools/wf), and (in D8) [Configuration Management](https://www.drupal.org/documentation/administer/config).
  
  > **Comments:**
  > **username_2**: 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.  
  
  ---
  
  