migrate_wizard
Introduction
The module provides a user-friendly solution for seamless content migration.
Features
Introduction
The module provides an easy-to-use solution to migrate content without programming.
Features
- Generate connections to the source database without editing the settings.php file.
- You can add more than one source database.
- You can migrate from Content Type to Vocabulary, to Paragraph, and vice versa.
- You can migrate two content types in source to the same destination. Unify content, vocabularies, etc.
- Migrate only the files you are going to use. If you are going to use all of them, you can migrate them independently.
- Migrate fields or entities from file or image type to media type.
- Migrate Path aliases
- Users owning content.
- Migrate only a number of nodes, specific nid, or from a date.
- Migrate Field collections to paragraphs and paragraphs with nesting. Start with the last child and end with the parent or grandparent.
- Migrate drupal 7 translations made with the Content Translation (core) module Entity translation in progress.
Post-installation
Once installed, go to migrate-wizard/list-databases/create-mw-database and add a connection configuration to a database with source data from drupal 7.
This is done with the same data that was used in the settings.php file
If you want to use environment variables to hide sensitive users or passwords, you can use them in the host, database, username, password fields.
Once your database is configured, we will go to the role mappings, if a role does not exist in your target drupal, you can create it on the fly!
Next we can configure the migration of users, for this we check the Build migration config option in the Users tab and map the fields that the user has if we need it.
In the rest of the migrations the process is similar, with some particularities that we show below:
In the Mapping formats editors tab, we select each correspondence between the format editors that are listed (the source ones) and
those that appear in the selectors (the destination ones).
The source fields will always be shown in the list and the destination fields in the selectors, where we will mark their correspondences when appropriate.
When we click on the Node list tab we will see that the list is empty. If we click on the "Read origin nodes" button, a row will be shown in the list for each type of content that exists in the Drupal 7 source.
We click on "Manage fields origin nodes" in the one we want to migrate and we will go to a page where we will configure the migration of that type of content.
On this page, we will see some checkbox options:
- Build migration config: If we mark it, when saving a migration configuration will be generated (drush cex -> file.yml).
- Preserve nid: The nid of each node will be kept when migrating.
- Import users: If users have been migrated before, each node will keep the owner it had at the source.
- Import path alias: The path aliases that each node has at the source will be migrated.
- Default translation (xx): This option cannot be disabled, it is simply informative, it indicates which is the default language of drupal at the source.
- Additional translations that can be migrated: If we check each translation, an additional file (file_xx.yml) will be generated to migrate each translation.
Below you can see a fieldset with the following title:
"Select a bundle destination type"
In which we must select the type of content, vocabulary or destination paragraph to which we want to migrate.
When we select the one we need, the fields that have what we have selected will be loaded by ajax in the options of the list below.
In the list below you can see the Drupal 7 fields with a selector in which we will select the destination field.
There are some special cases:
Fields with taxonomy or similar relationships:
A field will appear indented in which we will select which other migration the relationship corresponds to, to make the lookup of the id for that migration.
File or image type fields:
If the destination is file or image type (without media) you should not touch the indented selectors, these should only be used in case the destination is of media type, even if it is not media in the source, the module will transform it. To do this you must select what type of media you want in the destination and which field of the media entity will receive the data.
Similar projects
Although there are other migration modules available, our module stands out for its easy-to-use interface, field mapping capabilities and dedicated support for transitions from Drupal 7 to Drupal 10.