COVID19 Response - The Monarch Digital team is standing by to help you with any website needs you have during these difficult times. If you find yourself in need of web services please give us a call or reach out by email.
Monarch configured custom migrations using the core Drupal 8 migration module to migrated D6 content including nodes, users, files, and menu links. While the core D6 to D8 upgrade path was supposedly complete at that time, many contributed modules were still missing migrations. Theoretically, the automated upgrade path was supported and possible to use. This was in fall 2016, shortly after Drupal 8.2.0 was released. However, it is my understanding that the automated upgrade path still isn’t feasible with 8.3.x.
Migrations imported using Drush
We used the helper modules Migrate Plus (https://www.drupal.org/project/migrate_plus) and Migrate Tools (https://www.drupal.org/project/migrate_tools) which allow grouping migrations and supports running individual migrations with Drush. There was no way to run migrations from the UI other than a complete automatic upgrade (instead of custom migrations). It's my understanding that this still does not exist in 8.3.x but we haven't done a more recent migration so some features/configurations may have changed.
We ran individual migrations by group (users, then files, then taxonomy, then nodes) using the Migrate Tools drush commands.
Incremental migrations and highwater fields
There was no supp ort yet for "highwater" fields to allow incremental migrations so all content was migrated at once. I don’t know the status of highwater fields in 8.3.x. We implemented a content freeze to prevent users from adding or updating any content between the migration and final deployment.
This kind of field is used to allow for incremental migrations, and see if content (already migrated) has been updated since the previous attempt, and then remigrate it. In Drupal 7 this would be implicitly set to the “changed” or last updated date field.
The core date module only supports single dates (this was prior to the new experimental date range module added in 8.3.0). As a work around, we added two separate single date fields for start and end dates and built the custom migrations (along with some theme work) to use the separate fields.
This might be a good place to bring up the frustration of modules getting added to core in an incomplete state or with missing features that were available previously in contrib.
Webform was not available at the time. Instead, they're using embedded third-party form from formstack (just embedded iframes, no direct integration with Drupal).