Best approaches to Drupal migration
Migrating content and its linkages between sites has always been one the more difficult tasks to master in the world of Drupal. In the past, site builders and developers would have to write lots of code to set up the migrations and field mappings. Migrating between Drupal sites is not quite as daunting of a task as migrating a site from another CMS, since many of the entities will be similar across sites, but is challenging none the less. The last time that I had looked at the migrate module, nearly a year ago, it took some time for me to understand how to properly create and set up all the required migration files and mappings. I recently needed to do some drupal-to-drupal (d2d) migration and was pleasantly surprised by how simple and powerful the migration UI has become thanks to some new features.
When you think of migrating content you likely think about the migrate module (or migrate d2d in this case). Without having to write a single line of code I was able to migrate the content and all of the linkages (images, files, author, tags, etc). If you are migrating from one drupal site to another it couldn’t be easier. You can now simply provide the database credentials for the source site and a wizard will step you through the entire process allowing you to choose which entities to migrate. Below is an example of the migrations that the module can generate for you.
Initially I was getting error messages from the “File” migration which resulted in only being able to get the user’s profile pictures to map properly. It wasn’t until I found this issue report that I discovered how to get the migration to completely work. I could see that the files were being migrated over to the correct location in the destination site's files folder, but for some reason the fields were empty in the migrated nodes. As I later learned the issue occurred because their file id(fid) was not being mapped to the node’s fields. In order to set up the linkage you have to use one of the migrate file classes, in this case, MigrateFileFid. By editing the generated migration and adding MigrateFileFid as the default value for the “Option: Implementation of MigrateFile to use” field in the “nodeevent” migration I was able to get the content to be 100% migrated and mapped.
Although the migrate module is likely the module that most people are familiar with and use the most, there are several other modules that perform similar actions including, uuid_features, and deploy module.
The uuid_features module allows you to packages the selected nodes into a feature that you create. Once you've generated the feature you can enable it on the destination site and it will recreate the nodes from the source site. In my limited testing of the module I was able to easily package up the content, and when I enabled the feature it created the nodes, however no author was associated with that node. I can assume this is happening because no users are not “migrated” or packaged into a feature.
The final module to be discussed in this article is the deploy module. As the project page stats, “The Deploy module is designed to allow users to easily stage content from one Drupal site to another. Deploy automatically manages dependencies between entities.” The setup process involves creating a REST endpoint on the source site and then using the services module, to make calls to that endpoint on the destination site. You can read this article, which guides you through the entire setup process step by step.
In Summary each module has its own advantages and disadvantages. If you need to migrate the entire site the migration module is going to be your best bet, however if you want to migrate only a select number of nodes then the uuid_features or deploy module should likely be chosen and these require no mappings to be set up ahead of time.
