Tips for writing Drupal migrations and understanding their workflow

We have presented several examples so far. They started very simple and have been increasing in complexity. Until now, we have been rather optimistic. Get the sample code, install any module dependency, enable the module that defines the migration, and execute it assuming everything works on the first try. But Drupal migrations often involve a bit of trial and error. At the very least, it is an iterative process. In this chapter we are going to see what happens after import and rollback operations, how to recover from a failed migration, and some tips for writing the migration plugin files.

Importing and rolling back migrations

When working on a migration project, it is common to write many migration plugin files. Even if you were to have only one, it is very likely that your destination will require many field mappings. Running an import operation to get the data into Drupal is the first step. With so many moving parts, it is easy not to get the expected results on the first try. When that happens, you can run a rollback operation. This instructs the system to revert anything that was introduced when then migration was initially imported. After rolling back, you can make changes to the migration plugin file and rebuild Drupal's cache for the system to pick up your changes. Finally, you can do another import operation. Repeat this process until you get the results you expect. The following code snippet shows a basic Drupal migration workflow:

# 1) Run the migration.
$ drush migrate:import first_example

# 2) Rollback migration because the expected results were not obtained.
$ drush migrate:rollback first_example

# 3) Change the migration plugin file.

# 4) Rebuild caches for changes to take effect.
$ drush cache:rebuild

# 5) Run the migration again.
$ drush migrate:import first_example

In all cases, first_example is the id of the migration to run. You can find the full code in Chapter 2!!!. Anytime you modify the plugin files, you need to rebuild Drupal's caches for the changes to take effect. This is the procedure to follow when creating the YAML files using Migrate API core features and placing them under the migrations directory.

Note: It is also possible to define migrations as configuration entities using the Migrate Plus module. In those cases, the YAML files follow a different naming convention and are placed under the config/install directory. For picking up changes in this case, you need to sync the YAML definition using configuration management workflows. This will be covered in chapter !!!.

Stopping and resetting migrations

Sometimes, you do not get the expected results due to an oversight in setting a value. On other occasions, fatal PHP errors can occur when running the migration. The Migrate API might not be able to recover from such errors. For example, using a non-existent PHP function with the callback plugin. When these errors happen, the migration is left in a state where no import or rollback operations could be performed.

You can check the state of any migration by running the drush migrate:status command. Ideally, you want them in Idle state. When something fails during import or rollback you would get the Importing or Rolling back states. To get the migration back to Idle you stop the migration and reset its status. The following snippet shows how to do it:

# 1) Run the migration.
$ drush migrate:import first_example

# 2) Some non recoverable error occurs. Check the status of the migration.
$ drush migrate:status first_example

# 3) Stop the migration.
$ drush migrate:stop first_example

# 4) Reset the status to idle.
$ drush migrate:reset-status first_example

# 5) Rollback migration because the expected results were not obtained.
$ drush migrate:rollback first_example

# 6) Change the migration plugin file.

# 7) Rebuild caches for changes to take effect.
$ drush cache:rebuild

# 8) Run the migration again.
$ drush migrate:import first_example

All the commands above are provided by Drush itself. The Migrate Tools module is a migration runner that offers additional commands and provides extra features to some of the ones listed above. It adds the migrate:tree command to show a tree of migration dependencies. For migrate:import, it add additional flags like --group and --continue-on-failure. You can use the following to know which commands are available in your installation and get details on usage:

# List of all migration related commands.
$ drush list --filter=migrate

# Get information on usage and available flags using --help
$ drush [command-name] --help

Tip: You can use Drush command aliases to write shorter commands. For example, drush mim first_example to start an import operation. When using drush list that aliases appear in parenthesis next to the command name.

The errors thrown by the Migrate API might not provide enough information to determine what went wrong. An excellent way to familiarize yourselves with possible errors is by intentionally braking working migrations. In the example repository for this book there are many migrations you can modify. Try anything that comes to mind: not leaving a space after a colon (:) in a key-value assignment; not using proper indentation; using wrong subfield names; using invalid values in property assignments; etc. You might be surprised by how Migrate API deals with such errors. Also note that many other Drupal APIs are involved. For example, you might get a YAML file parse error or an Entity API save exception. When you have seen an error before, it is usually faster to identify the cause and fix it in the future. In chapters !!! we will talk about debugging migrations.

What happens when you rollback a Drupal migration?

In an ideal scenario, when a migration is rolled back it cleans after itself. That means, it removes any entity that was created during the import operation: nodes, taxonomy terms, files, etc. Unfortunately, that is not always the case. It is very important to understand this when planning and executing migrations. For example, you might not want to leave taxonomy terms or files that are no longer in use. Whether any dependent entity is removed or not has to do with how plugins or entities work.

For example, when using the file_import or image_import plugins provided by Migrate File, the created files and images are not removed from the system upon rollback. When using the entity_generate plugin from Migrate Plus, the created entity also remains in the system after a rollback operation.

In the next chapter we are going to start talking about migration dependencies. What happens with dependent migrations (e.g. files and paragraphs) when the migration for host entity (e.g. node) is rolled back? In this case, the Migrate API will perform an entity delete operation on the node. When this happens, referenced files are kept in the system, but paragraphs are automatically deleted. For the curious, this behavior for paragraphs is actually determined by its module dependency: Entity Reference Revisions. We will talk more about paragraphs migrations in future chapters.

The moral of the story is that the resulting state of the system might be affected by other Drupal APIs. And in the case of rollback operations, make sure to read the documentation or test manually to find out when migrations clean after themselves and when they do not.

Note: The focus of this section was content entity migrations. The general idea can be applied to configuration entities or any custom target of the ETL process.

Re-import or update migrations

We just mentioned that Migrate API triggers an entity delete action when rolling back a migration. This has another important side effect. Entity IDs (nid, uid, tid, fid, mid, etc.) are going to change every time you rollback and import again. Depending on auto generated IDs is generally not a good idea. But keep it in mind in case your workflow might rely on them. For example, if you are running migrations in a content staging environment, references to the migrated entities can break if their IDs change. Also, if you were to manually update the migrated entities to clean up edge cases, those changes would be lost if you rollback and import again. As described in the previous section, test data might remain in the system after a rollback so make sure to clean things up when deploying to production environments.

An alternative to rolling back a migration is to not execute this operation at all. Instead, you run an import operation again using the --update flag. This tells the system that in addition to migrating unprocessed items from the source, you also want to update items that were previously imported using their current source values. To do this, the Migrate API relies on source identifiers and map tables. You might want to consider this option when your source changes overtime, when you have a large number of records to import, or when you want to execute the same migration many times on a schedule.

Note: On import operations, the Migrate API issues an entity save action.