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.