Migrating to Drupal 8: Things to Know
Developers who leverage the incredibly useful Migrate Framework in Drupal 7 know that migrating into this version of Drupal from a variety of data sources is a smooth, streamlined process.
It provides various tools for mapping source data to destinations in Drupal 7, with additional methods to massage incoming data and take various actions after a record of data is saved. The framework is, without a doubt, one of the most indispensable tools in a Drupal developer's bag of tricks when migrating into Drupal 7.
But Drupal 8 does not include a version of this module - and this is because...
Migrate is Now a Part of Core!
With the release of Drupal 8.1.0, three modules were added to facilitate custom migrations as well as migrations/upgrades from Drupal 6 or 7 to Drupal 8, right from the admin:
- Migrate Drupal
- Migrate Drupal UI
The Migrate module provides the tools to define and build custom migration plugins. The Migrate Drupal module provides methods for migrating Drupal 6 or Drupal 7 source data to Drupal 8, and the Migrate Drupal UI module provides a user interface for a guided migration from Drupal 6 or 7 to Drupal 8.
Users looking to do assisted upgrades to Drupal 8 can now do so, much more easily than they used to be able to before. The admin screen will ask you for the connection information to your Drupal 6 or 7 database, and then show you an overview screen of what will be migrated (and what will not). Another click of a button and before you know it, your old Drupal site is now migrated to Drupal 8!
What to Expect
Out of the box, the core migration is able to migrate the following items with virtually no additional work required:
- Content types
- Field instances
- Field data
- Taxonomy terms
- Book items
- Various other aspects of Drupal core, like actions and forums
Since the core provides the boilerplate needed to scaffold out content types, fields, field instances, and other features, getting up and running is faster than before. In my experience, taking a bare Drupal 8 install and migrating to it from a Drupal 7 source (with most things intact) took no longer than 30 minutes to complete, which is very impressive!
Previously, I would have to setup the Drupal site and create all the content types, fields, and field configurations myself. This could take the better part of a day or two depending on the size of the project and all of this would need to happen before I could even start on the migration classes. Now, I can just plug in the database credentials with a fresh install of Drupal 8 and enjoy a cup of coffee.
If you have a fairly straightforward site comprised of basic content and very few modules or custom code, the core migration will most likely work on the first shot. However, there were a few roadblocks I ran into.
Dealing with Complexity
The Drupal to Drupal migration capability via core is not quite complete yet. It is listed in core as experimental and is still in an alpha state. There is a lot of promise in the work done so far, but there are some outstanding issues that need to be resolved before the assisted migration experience becomes a more viable option for the upgrade from Drupal 7, especially with regard to more custom and complex implementations.
Some of the more significant outstanding issues include:
- Upgrade path for Entity Reference field from 7.x
- Addition of the substr process plugin
- Roles duplication instead of existing roles being updated
- Custom view modes not migrating from Drupal 7 to Drupal 8
- Inability to use migration plugins directly
However, support for the entity reference field type has yet to be resolved. For those who have sites using a lot of reference fields (think taxonomy term, node, and user references), it is recommended to wait until this issue is resolved prior to migrating. Views and custom date formats also do not seem to migrate over, and will need to be recreated.
Real World Example: Migrating to Drupal 8
I ran a version of 8.1.x that includes all of the patches to date to test out how the migration of a recent site I was working on would fare.
The core migration process, with the aforementioned patches, works without error. However, there is no support for non-core field types (for example, the Address field) yet. Contributed modules that extend the core and provide new field types via the Field API are unsupported.
In my example, this didn't present too much of a barrier - the test site only had a handful of records that stored any address related information and I was able to just recreate this data. However, I can easily picture scenarios where the inability to migrate this data can be a complete showstopper - for example, an ecommerce application that might store thousands of geolocated customer addresses.
With over 800 modules that add or extend Drupal field types, a method that will allow those modules to hook into the core process to define an upgrade path that can take advantage of the new migration process, rather than handling it via custom migrations, will be needed.
In the meantime, the configuration I have running appears to work, which leaves the task of re-architecting how to create and curate content. With the migration of a bulk of the site out of the way, the focus can now shift to bigger changes.
Until you can set dependencies on core migrations without copying out and recreating them in your module, getting a hybrid migration setup can be very tedious. You will find that to get a lot of the elements in place for a migration, you will be copying a lot of templates even if you don't need to modify them. This is due to one of the issues mentioned above where you cannot specify dependencies on existing migration templates.
Additionally, it is hard to find a path forward when you hit a wall. Documentation is a bit bare, as the core migrate functionality and contributed modules are constantly evolving and documenting them in their current state would not be productive. As things begin to stabilize, additional documentation with more examples should start to surface, which will make it easier to craft custom migration procedures.
Finally, it will be nice when there is a comparable UI for migrations as exists in the migrate framework for Drupal 7. While I am comfortable with the command line, I miss many of the aspects the UI had provided. Fortunately, there is progress being made on implementing this feature, as well as being able to control migrations from the admin.
Kudos to all involved as this is a major step forward for both assisted upgrades of Drupal and migrations of non-Drupal sources into Drupal 8. I have faith that those involved in the development of the migration modules will move forward pretty quickly to iron out the kinks and pain points over the next few releases.
Have you had any experience with migrating or upgrading to Drupal 8? Feel free to join the discussion by commenting below and sharing your thoughts on the new process.