There's been a series of questions pop up in #drupal-migrate in IRC over the past few days and weeks about how to handle configuration management for migrations. There's several options available, I’d like to suggest one that seems to work really well for us (and maybe you as well). Other approaches exist (see mentions in blog post by Mike Ryan or migrate_manifest).

But first a little bit about config in Drupal 8. Config is provided by modules and install profiles at install time. Once the config is imported into the site, it goes into “active” storage, where it can be acted upon and changed using various GUI tools. Want to change the site’s name, we visit the appropriate admin page and change it there. That setting is saved in “active” config.

But wait, I thought as of 8.1, that migrations weren’t config items any more. They aren’t, if you want to migrate everything using Drupal core’s, one-go, update mechanism. Except for the most simple of websites, using the one-go approach simply doesn’t scale. So you are back to creating config entities again. But this time, they are provided by migrate_plus in contrib.

Config entities created by migrate_plus are no different than other config entities created for a site. They are stored in “active” config and can be exported into “sync”. I take full advantage of that and follow a 3 step process to modify the migration configurations. Once the config is exported, we add it to git and deploy to dev, staging and live using our normal git workflow.

1. Export config (drush cex -y || drupal config:export)
2. Modify the config to my desire
3. Re-import the modified config (drush cim -y || drupal config:import)

It is simple. It follows how we manage all our other configuration on the site. I like it because we can use the same approach everywhere. Using my initial example, we can change the site name, export that to config. And in the same manner, change a migration config entity.

You might be asking yourself, but what about writing custom process plugins. For that, we create a custom module to contain those process plugins. Then add a config dependency in the migration on the custom module.

Additional note: we also take advantage of config_installer. A install profile that allows you to install the site using a site’s “sync” config.