0

I have a Drupal 6 site with three custom content types. We have tried using the Migrate Drupal UI module to migrate these to our new Drupal 8 site, but this resulted in all of the plain text fields being imported as long text fields (field type string_long when they should be string).

To fix this, I deleted all content of those types, exported the configuration created by the UI module with drush cex and used drush cim to re-import the YAML config files after changing all instances of string_long to string.

After about 3 hours of fiddling with this, I finally had a working D8 configuration with the same fields, forms and views as the original D6 site. Now it's time to migrate the content data across.

I have spent another ~6 hours researching and experimenting on how to do this, having tried the views_data_export and Feeds modules, as well as reading several resources on creating custom migration modules.

The former solution was tedious to set up and the default form for creating a feed type wouldn't allow me to create nodes with the original node IDs. So I tried to step through the code and figure out how to extend the module by myself, since the API documentation is severely outdated. This got me nowhere but extremely tired, confused and frustrated, and about 2 hours closer to my eventual demise.

I'm not even game to try the latter solution, since that would probably be just as hard. So now I've started investigating the DB structure in the hope of writing my own SQL update script...only to discover that there are not only node, node_field_data, node_revision and node_field_revision tables to contend with, but also node__<field_machine_name> and node_revision__<field_machine_name> tables for every defined field (35 of them in my case)!

This seriously can't be this hard! Surely I must be missing some crucial piece of documentation from my Google search results. So what would be the easiest method to accomplish what I want?

Improve this question
5
  • Asking for the easiest or best of something always is an opinion-based thing. What's easy for you might be difficult for others. Some might say you should hook into the D6 database from your new D8 site and import all content programmatically using a batch process, others might say go for Migrate and adjust it the way you need it. – leymannx Mar 24 '20 at 13:51
  • @leymannx I totally agree, but perhaps I gave you the impression that I expect the 100% undeniable "best" solution. That is obviously impossible to give though, for the reasons you stated. Hence I am really just looking for ideas that I could explore further on my own. – Kenny83 Mar 24 '20 at 14:03
  • The two options here is the inline D6>D8 migration, or to use the Migrate API + Migrate Plus (if needed) directly to write your own migrations. The latter has example migrations you can look at. There is never going to be a case or scenario where you will want to write a manual SQL migration script. You should not need Views or Feeds for this - the Migrate API has source plugins that can connect to databases or other data sources to query and pull data. – Kevin Mar 24 '20 at 15:30
  • Thanks @Kevin! If you write up your comment as an answer I'll gladly accept it :D – Kenny83 Mar 24 '20 at 15:35
  • Does that technically answer it though? – Kevin Mar 24 '20 at 15:35
0

The two options here is the inline D6>D8 migration, or to use the Migrate API + Migrate Plus (if needed) directly to write your own migrations. The latter has example migrations you can look at. There is never going to be a case or scenario where you will want to write a manual SQL migration script. You should not need Views or Feeds for this - the Migrate API has source plugins that can connect to databases or other data sources to query and pull data.

Here is a docs page outlining how to migrate from a SQL source:

https://www.drupal.org/docs/8/api/migrate-api/migrate-source-plugins/migrating-data-from-a-sql-source

You would set the two databases side by side in MySQL, create a connection setting as mentioned and create a source. The class controls certain aspects of querying and the migration YAML(s) map the fields to their new destinations.

For all the nuanced aspects, I would recommend joining the migration channel in the Drupal Slack, people are always willing to help there.

Improve this answer
1
  • Thanks mate, and re: drupal slack's migration channel, I have asked questions there before without getting much response. I'll give it a go next time though ;-) – Kenny83 Mar 24 '20 at 15:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.