I'm trying to custom-migrate D7 to D8 articles with references to file(images), taxonomy terms, and users(uid). Do i have to migrate the whole group all these entities belong to with

drush migrate_import --group=mygroup

to keep the references all right?

Or is it somehow possible to run one subsidiary migration and still keep the references, i mean

drush migrate_import mymigration



The --execute-dependencies option will cause all the migrations your "main" migration depends on to run first, so all references are resolved:

drush mi --execute-dependencies mymigration

Of course, 'mymigration' needs to reference the migrations it depends on in migration_dependencies:

    - my_file_migration
    - my_user_migration
  • Thanks for the reply, i have additional questions as mine dependencies still dont work: May 29 '17 at 7:20
  • Thanks for the reply, i have additional questions as mine dependencies still dont work: * should i run drush mi with --group=mygroup or better without a group specification with `my_main_migration' only? * i have 3 migrations: user (works even with picture), file (images, they got imported but not related to the node), and node migration which is the main one that depends on user and file migrations. While users and files are migrated ok into D* instance, nodes are imported but withour references to uid and fid of the child migrations, although i have specified: (see next comments) May 29 '17 at 7:28
  • Here is my code: 'field_logo/target_id': plugin: migration_lookup migration: luxus_files no_stub: true source: fid uid: plugin: migration_lookup migration: luxus_user source: uid no_stub: true migration_dependencies: required: - luxus_user - luxus_files May 29 '17 at 7:36
  • process plugin 'iterator' solved the trouble, it diggs 'fid' out of image fields like a breeze May 30 '17 at 8:56

I haven't done a D7 to D8 migration, but for a migration to D8 from an sql source, I find it's best to do a "child" migration before its "parent. So do the users, terms, and files before migrating the articles. And then if you roll back, do that in the reverse order: parents before children.

This blog post was helpful to me: http://www.mediacurrent.com/blog/migrating-content-references-drupal-8

This is the way I organize things in my migrations...

In the child migration:

    plugin: migration_lookup
    migration: parent_migration
    source: my_parent_id

In the parent migration:

# for the label field and any other non-reference fields, create 'stub' values in this manner:
    plugin: get
    source: my_label_field
    plugin: default_value
    default_value: 'Stub Label'
  plugin: migration_lookup
  migration: child_migration
  source: my_child_items

Note: if some of your parent entities don't have any child items, you can use the skip_on_empty process plugin as follows to make sure those parent entities are still migrated properly. (If child items are required for all parent entities, you can omit from the migration any parent entities with missing children by changing the 'method' from 'process' to 'row'.)

    plugin: skip_on_empty
    method: process
    source: my_child_items
    plugin: migration_lookup
    migration: child_migration
  • Thanks for the snippet. btw what is the parent_id: section about? do i have to mention the parent field in the child migration yml file? May 29 '17 at 7:42
  • Sorry to have caused confusion; in your case (users, terms, and files), the parent_id doesn't make sense. It depends on what you're migrating. An example in which "parent_id" would make sense is the migration of taxonomy terms and vocabularies: the terms would need to reference the "parent" vocabulary, using "vid" as the parent/vocabulary id.
    – user72086
    May 29 '17 at 13:39

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.