One of the most daunting challenges you will face as a Drupal developer is the 'database dilemma.' You have spent weeks building new content types, views, and complex logic on a development environment. Meanwhile, your live production site has been busy accumulating new user comments, blog posts, and account registrations. When the time comes to launch your new features, you realize the problem: how do you move your structural changes to the live site without overwriting the new data created by your users?

Because Drupal stores both configuration (the structure of your site) and content (the data inside that structure) in the same database, a simple database dump and restore will wipe out any content added to the live site since your last sync. To solve this, you need a deployment strategy that separates configuration from content. In this guide, we will explore the most effective workflows to merge your development work into a live Drupal site safely.

Understanding the Configuration vs. Content Divide

To master Drupal deployment, you must first understand what can be moved safely. In the Drupal ecosystem, 'Configuration' refers to things like content type definitions, field settings, Views configurations, and system settings. 'Content' refers to the actual nodes, taxonomy terms, files, and user data.

The golden rule of modern Drupal development is: Configuration moves from Development to Production, while Content moves from Production to Development.

If you follow this rule, you never have to worry about merging databases. Instead, you treat your configuration as code. When you want to update the live site, you don't touch the database directly; you 'import' the configuration changes you made in development.

Method 1: The Features Module (Ideal for Drupal 7 and Legacy Sites)

For many years, the Features module was the industry standard for exporting database configuration into code. While Drupal 8 and above have built-in configuration management, Features remains a powerful tool for bundling related functionality.

How to use Features for Deployment

  1. Identify the components: On your development site, go to the Features UI and select the content types, views, and permissions you have created.
  2. Export to code: Features will generate a custom module containing all these settings in .inc and .info files.
  3. Deploy the module: Move this new module to your production site's /sites/all/modules directory via Git or SFTP.
  4. Enable and Revert: Enable the module on production. If the feature ever becomes 'Overridden' (meaning the database differs from the code), you can 'Revert' the feature to force the production database to match your development code.
# Using Drush to revert features on production
drush fr-all -y

Method 2: Content Migration with Node Export and Deployment Suite

Sometimes, you aren't just moving configuration—you might have created 'static' content on development (like a complex 'About Us' page) that needs to go to production. Alternatively, you might need to sync content between two live environments.

Using Node Export

The Node Export module allows you to take specific nodes and turn them into a file format (like JSON or CSV) that can be imported into another site. This is particularly useful when combined with the Delete All module if you are doing a clean sweep of specific content types.

The Workflow: 1. Export nodes from Dev using drush node-export. 2. On Production, use drush delete-all for that specific content type (if you are replacing old versions). 3. Import the nodes using drush node-export-import.

The Deployment Suite

For more complex scenarios, the Deployment suite (Deploy module) allows you to manage dependencies. For example, if you move a node that references a specific taxonomy term, the Deployment suite ensures that the term is moved along with it to prevent broken references.

Method 3: The Scripted Database Update Workflow

If you prefer a more manual, high-control approach, some developers opt for a scripted workflow. This is often used when the changes are too complex for Features or when you are dealing with legacy systems.

  1. The Dump and Script Approach: You take a dump of the production database and bring it down to your local machine. You apply your changes there.
  2. The Reverse Sync: Instead of moving the DB up, you write a script (often using Drush or custom PHP updates in a .install file) that performs the structural changes.
  3. Update Hooks: Using hook_update_N(), you can write code that adds fields or changes settings. When you push your code to production and run drush updb, Drupal executes these changes directly on the live database without affecting content.
/**
 * Add a new field to the 'Article' content type.
 */
function mymodule_update_7001() {
  if (!field_info_field('field_new_meta_data')) {
    $field = array(
      'field_name' => 'field_new_meta_data',
      'type' => 'text',
    );
    field_create_field($field);
  }
}

Method 4: Standardizing the Production-to-Dev Flow

To minimize conflicts, the best practice is to ensure your development environment is always a mirror of production before you start new work. This is often called the 'Downstream Sync.'

  1. Pull Production Data: Regularly import a sanitized production database dump to your local dev environment.
  2. Develop Features: Build your new functionality on top of the latest live content.
  3. Export Config: Use Features or Drupal's Configuration Management (CMI) to capture those changes.
  4. Push Code: Deploy only the code/configuration files to production.
  5. Import Config: Run the config import on production.

This workflow ensures that you are always testing against real-world data, reducing the risk of 'it works on my machine' bugs.

Frequently Asked Questions

When moving a database from Dev to Prod, you may find absolute URLs (e.g., dev.mysite.com/image.jpg). You can use a regex find-and-replace on your SQL dump before importing it, or use the Search and Replace Scanner module to fix these links directly in the Drupal interface.

Can I use database 'diff' tools to merge changes?

While technicaly possible, database diffing is extremely difficult in Drupal because of the way IDs (like nid or uid) are auto-incremented. If Dev and Prod both create a new node, they will both try to use ID #101, leading to a primary key collision. It is much safer to use UUID-based systems or configuration export tools.

What if I accidentally overwrote production content?

If you have a backup, you can perform a partial restore of the specific tables (like the node, field_data_*, and users tables). However, this is risky due to relational integrity. Always perform a full database backup immediately before any deployment.

Wrapping Up

Merging development changes into a live Drupal site doesn't have to be a gamble. By adopting a 'Configuration as Code' mindset—using the Features module for structure and Node Export or Deployment for data—you can maintain a seamless bridge between your environments.

Remember, the most stable workflow is one where content flows down to developers and configuration flows up to the server. Standardizing this process with Drush and version control like Git will not only save your content but also your sanity.