Background
When we move the Drupal 7 workflow information from the old site to the new site we need to keep the information intact and accurate. To do this, we need a plan which will account for:
Consideration | Challenges | Ideas |
---|---|---|
User Accounts Should Be The Same |
| |
Date / Times Should Be The Same |
|
|
Workflow Action Notes Should Be The Same |
|
|
If we import the data into the new site, but continue to use the old site for a bit longer, we should also have a plan to keep the audit/decision information synced between the two. |
| |
If direct drupal Migration is not an option |
|
|
Comparison of Migration Options
Option 1: Find Script on Internet | Option 2: Write a script ourselves using Drupal Migration Code | Option 3: Write a script ourselves using direct database calls | Option 4: Hand migrate | |
---|---|---|---|---|
Description | In this option, we have tried a related option that is available on the internet and takes the idea if someone already did migration in order to investigate. | In this option, We have to study internal architecture how the workflow, rule modules module functional in the Drupal 8 sites, and based on those inputs we need to create a custom module that will migrate the data from drupal 7 to drupal 8. | Similar to the option 2, but using direct database calls instead of writing php code to perform the migrations. | In this option, We have to migrate workflow rules from Drupal 8 administrator by taking the reference which we had on the Drupal 7 site. We will also need to hand migrate the historical Access and Publishing Requests that are contained within the current system. This would be done through the UI interface by replicating the original not by copy the data through the database. |
Workflow Rules | ||||
Pros |
|
|
| |
Cons |
|
|
|
|
Data |
|
|
workflow_node workflow_node_history workflow_scheduled_transition workflow_states workflow_transitions workflow_type_map workflows
config config_snapshot workflow_transition_schedule workflow_transition_history |
|
Pros |
|
| ||
Cons |
|
| ||
Notes | On the basis of research on the internet, there is no direct way available to migrate workflow and rules directly from Drupal 7 to Drupal 8. Result: Failed, I have tried to migrate workflow and rules data through the brush but the process is not supported to migrate the data from D7 to D8. Useful Link: https://www.drupal.org/docs/upgrading-drupal/upgrade-using-drush 2: Tried to import workflow state by adding code and followed steps mentioned here in this link https://www.drupal.org/docs/upgrading-drupal/upgrade-using-drush But there is not success found with that. Result: Failed, As node was not imported to the D8. 3: In order to migrate rule from D7 to D8, I have used a few modules with providing missing functionality in Drupal 8. Here is the list of those modules.
Result: Failed 4: I have tried to apply the patch which is having on Drupal community Result: Failed | On the basis of the POC on this approach, the D7 and D8 database scheme has been changed significantly. In drupal 7, workflow module with a separate table w.r.t their functionality module. whereas in Drupal 8, it will use a common table except for workflow history and transition. | On the basis of the research that we can make the workflow settings manually which included state and transition and we will import the history by using a script that will get the data from the Drupal 7 site. |
Outstanding Questions
(Not a question) Currently we have a feeling that a possible approach would be to move the Workflow Rules by hand between the D7 and D8 systems and move the Data using a sql script or php code; this would be a split approach.
What research needs to be done to determine how to import existing API Request and API Publishing documents from D7 to D8 such that they will be associated with the workflow system?
What research needs to be done to determine how to use a sql script or php code to transfer the audit history (ie.
workflow_transition_history/schedule
tables) from D7 to D8?When the research is complete, will we be able to do a final “fresh” migration of the data? Can we repeat that process later as well?