Skip to main content

When working on Drupal migrations, developers often assume that adding a new field to the process section will seamlessly update existing content. However, unless explicitly handled, Drupal’s migration system does not automatically apply changes to previously migrated records. This oversight can lead to data inconsistencies, incomplete content structures, and potential frustrations for both developers and stakeholders.

In large-scale Drupal implementations, especially those involving external data sources — understanding how Drupal’s migration framework processes changes is crucial. Simply adding a new field and re-running the migration might not have the desired effect, and failing to properly account for data updates can cause unexpected gaps in content delivery.

 

The problem with partial migrations

Drupal’s migration framework is designed to be efficient, avoiding unnecessary reprocessing of existing records unless explicitly told to do so. This means that when a new field is added to the migration process, only newly imported records will include the additional field — leaving previously migrated content untouched.

For example, if a migration initially imports title, summary, and author, but later you add field_url, Drupal won’t automatically update older records with URLs unless you instruct it to do so. This can lead to a fragmented dataset where some nodes have URLs and others don’t, requiring additional effort to resolve discrepancies.

 

Ensuring updates apply to existing records

To apply changes across all migrated content, developers need to explicitly instruct Drupal to update existing records. There are three primary methods for achieving this:

1. Using the update flag
  The simplest way to update existing records is by re-running the migration with the `--update` flag:

drush migrate:import fr_migrate_product_json --update

  This ensures that previously imported nodes are reprocessed and updated, without duplicating content.

2. Rolling back and re-importing
  If a more significant change is required, developers can rollback the migration before re-running it:

drush migrate:rollback fr_migrate_product_json
drush migrate:import fr_migrate_product_json

This method is more aggressive as it deletes and re-imports all records, ensuring a clean slate. However, it should be used cautiously in production environments where content modifications might have been made manually after migration.

3. Running a manual batch update
In cases where a migration rollback is not an option, developers can write a custom script to update only the new field for existing records. This can be achieved through a Drupal batch process or an entity query to fetch and update records programmatically.

 

Minimising disruption in production environments

Applying migration updates to an active Drupal site requires careful planning. Here are some best practices to ensure a smooth transition:

  • Test updates in a staging environment first
    Running `--update` or `rollback` in production without validation can lead to unexpected data loss. Always test the impact of migration changes before applying them to live systems
  • Back up your database
    Before making large-scale migration updates, ensure a backup is available. In case something goes wrong, being able to quickly restore the previous state is critical
  • Use logging and debugging. If migration updates don’t apply as expected, enable logging to inspect migration messages
drush migrate:messages fr_migrate_product_json

This provides insight into why certain records may not be updating as intended.

 

The cost of neglecting migration updates

Failing to properly update existing records can lead to misaligned data, missing information, and unnecessary troubleshooting efforts. For organisations relying on structured content in Drupal—especially in research, government, and large-scale publishing—ensuring migration updates are properly executed can mean the difference between a functional system and an unreliable content repository.

By understanding the nuances of Drupal’s migration system and proactively addressing update challenges, developers can create robust, future-proof migration workflows. As the complexity of data integrations increases, so too must our approach to managing content updates effectively.

Related articles

Andrew Fletcher04 Apr 2025
Managing .gitignore changes
When working with Git, the .gitignore file plays a critical role in controlling which files and folders are tracked by version control. Yet, many developers are unsure when changes to .gitignore take effect and how to manage files that are already being tracked. This uncertainty can lead to...
Andrew Fletcher26 Mar 2025
How to fix the ‘Undefined function t’ error in Drupal 10 or 11 code
Upgrading to Drupal 10.4+ you might have noticed a warning in their code editor stating “Undefined function ‘t’”. While Drupal’s `t()` function remains valid in procedural code, some language analysis tools — such as Intelephense — do not automatically recognise Drupal’s global functions. This...
Andrew Fletcher17 Mar 2025
Upgrading to PHP 8.4 challenges with Drupal contrib modules
The upgrade from PHP 8.3.14 to PHP 8.4.4 presents challenges for Drupal 10.4 websites, particularly when dealing with contributed modules. While Drupal core operates seamlessly, various contrib modules have not yet been updated to accommodate changes introduced in PHP 8.4.x. This has resulted in...