Content migration - Managing migrations (Migrate tools)

In the previous posts we have talked about how to carry out an analysis, migration plan, how to code the different migrations and how to create plugins to provide more functionality to our migrations. In this post we will see how to manage migrations using the Migrate tools module.

Migrate tools

As already discussed in series 2, it is a contributed module (https://www.drupal.org/project/migrate_tools) that provides us tools to execute and manage migrations. It provides us with a series of drush commands to interact with migrations, including the ones listed below:

• migrate:status: To view the status of migrations.
• migrate:import: To import migrations.
  --limit: Number of elements that we want to migrate.
  --idlist: Comma separated list of source identifiers to migrate.
  --group: Migration group to be able to launch group migrations.
  --update: Force updating all previously migrated records and insert new ones.
• migrate:rollback: It reverts a migration.
• migrate:stop: It stops a migration.
• migrate:reset-status: It resets the migration status if it remains in an abnormal state.
• migrate:messages: It displays error messages for a specific migration.
• migrate:fields-source: It shows us information about the source content.

Furthermore, it provides an interface for launching migrations, this is found once the module is installed by accessing to the url “/admin/structure/migrate”. One of the limitations at this level is that you cannot rollback. So in this chapter we will focus on the drush command.

Running migrations

Once the migrate tools module and our migration module are installed, we will access the web system through the console and execute drush migrate: status or drush ms, with this command we can see the status of our migration or migrations and the extra information such as the migration group, the identifier of each of the migrations, the state in which the migration is in, the total number of source rows, the total number of imports, the total number of rows that have not yet been processed, and the date of the last time the migration was launched.

In order to launch the migrations, we can do it by using the command drush migrate-import or drush mim and then, the identifier of the migration or the group. If it is done through the identifier, we must have in mind that the dependencies will not be migrated to us and if these dependencies are required, the command will output an error. In the case of adding the group in the command with the --group parameter, it will launch the migrations consecutively, that is, from top to bottom, providing us with information about each one.

Once the migration is executed, if we run the drush ms command again, we will see that all the items are imported. We can also use the migrate: messages command to see if we have had any errors.

The use of rollback reverses the migration so that we can perform the migration as many times as we want. For this we must use the drush migrate-rollback command to which we can pass the migration identifier or the group.

In order to work with migrations we must keep in mind that any change made at the configuration files (yml) level will not be updated in the drupal system until they are changed at the database level and this will happen with the uninstallation and the installation of our migration module or doing a partial import of the configuration. For the latter, it is necessary to perform drush config-import --partial --source=modules/custom/mymodule/config/install

Conclusions

Throughout this series of posts we have seen that any content migration involves an analysis and a migration plan, code and management of them.