Learn to Migrate to Drupal for Drupal 8, 9, 10, and 11

Whether you're updating from Drupal 6 or Drupal 7, or importing data from some other source, you need to know about the migrate system in the latest version of Drupal. This tutorial provides an overview and links to additional tutorials where you can learn more about how all the individual parts work.

By the end of this tutorial you should have a better understanding of what the migration system is capable of and know where to find more information about how to use it.

To follow along with the rest of the migration tutorials you'll want to make sure you understand the following concepts and terms as they relate to Drupal migrations.

In this tutorial, we'll take look at the basic components of a migration and familiarize ourselves with some of the concepts and terminology needed to understand how the system works. We'll cover:

• What is a migration?
• Migration templates
• The extract, transform, load process
• Destinations and sources
• Additional Drupalisms

By the end of this tutorial you should be able to identify the various components that a migration is composed of, and explain at a basic level what each is responsible for.

Every migration is unique, which means there are loads of great examples you can review and learn from. We'll keep this tutorial up-to-date with our favorites and let you know how we think these examples might help.

In Drupal, there are 3 modules in core related to migration that you'll want to know about. These modules can help you import data into Drupal from disparate sources, or upgrade from a previous version of Drupal.

In this tutorial we'll look at what each of these core migration modules do, and talk about when you'll need to use them.

There's a whole ecosystem of contributed modules that build on the Migrate API in Drupal core. They do things like provide Drush commands for working with migrations, add new sources (CSV, JSON, etc.), add new destinations, provide code examples, and fill in other gaps. Think of these as the tools of the trade you’ll use to do your work. In most cases you’ll use these to do the migration, but then once the migration is complete you can remove them from your project.

Then there are the contributed modules that add features to your site. Like Flag, Paragraphs, or Webform. These modules often contain migration-related code that is intended to help make it easier to handle data specific to these modules. There is code in the Flag module, for example, that can help with knowing how to extract flagging records from Drupal 7, and for transforming that data into the format the module expects it to be in for Drupal 10. You might end up having to tweak it a bit, but at least you’re not starting from scratch.

In this tutorial we'll:

• Look at some of the most commonly used toolset modules.
• Explain what you can expect to find in standard contributed modules related to migrations.

By the end of this tutorial you should have a better sense of the various tools available to you for authoring a migration.

Before you begin a Drupal 6 or 7 (source) to Drupal 9 or 10 (destination) migration there are a number of things you should consider. Taking the time to plan your migration will help to ensure that you're successful. In this tutorial we'll take a high-level look at:

• Evaluating your existing Drupal 6/7 site for migration feasibility
• Preparing your source Drupal 6/7 site for a migration
• Preparing the destination Drupal site you're migrating to

By the end of this tutorial you should be ready to start assessing the feasibility of performing a successful migration, and begin making a migration plan.

When preparing to migrate from an older version of Drupal (Drupal 7 or previous) to the latest version of Drupal (Drupal 8 or later) you'll need to determine if the contributed modules you use are ready to go. The Upgrade Status module can give you a list of all the modules installed on your site, and information about the availability of a latest Drupal version. It's not perfect, and will still require some manual research for some modules, but it is a great start towards helping you plan for your migration.

In this tutorial we'll:

• Install the Upgrade Status module and use it to generate a status report
• Review the generated report
• Talk about using the Contrib Tracker project, and other methods for getting more details about the status of upgrades for any module

By the end of this tutorial you should be able to evaluate all the installed modules on your existing Drupal site and determine the status of a module release that is compatible with the latest version of Drupal.

It's not uncommon to patch, or customize, contributed modules during the lifetime of a site. It's important to know if you've done so when planning for a migration since you'll want to be sure that you don't lose any customizations when you start using an updated version of a module.

In this tutorial we will walk through using the Hacked! module to check for any alterations to your Drupal code base.

The Drupal-to-Drupal migration system is still a work in progress. As such, there are a few things that simply don't work, and a few others that still have kinks to be ironed out. In this tutorial, we'll look at some of the common hang-ups that we've encountered, the status of resolving those issues, and what your options are in the meantime.

The Migrate Drupal UI module allows you to execute a migration from older versions of Drupal to the latest version of Drupal. In this tutorial we'll:

• Run a full Drupal 6 to latest-Drupal (Drupal 8 or 9) Migration from the UI
• Explore the user interface as it exists
• Understand how we can deal with the output from our migration

In this tutorial we will run a site migration using Drush, and understand how to deal with any failures that occur.

Drupal core provides support for migrating data from Drupal 6 or 7. The templates provided in core migrate your data in a very specific way. They attempt to copy things verbatim whenever possible. However, you may wish to alter this for your migrations. In this tutorial we are going to explore the various ways that you can alter the existing Drupal-to-Drupal migrations to meet your needs.

Why use Migrate Upgrade and Migrate Plus? The short answer is: because it'll save you from having to type out a bunch of YAML by scaffolding a migration for you.

The contributed Migrate Plus and Migrate Upgrade modules are commonly used to aid in the process of performing a Drupal-to-Drupal migration. The combination of the two makes it easier to customize the configuration of individual migrations on a per-project basis by allowing you to edit each individual migrations configuration using the same mechanics that you would to write a custom migration.

It's not the only approach to making these changes, but for many people (including us), it's the most efficient way.

In this tutorial we'll:

• Get a more in-depth look at the role of the Migrate Plus and Migrate Upgrade modules
• Discuss the use cases for using them as part of a Drupal-to-Drupal migration

By the end of this tutorial you should be able to explain what both the Migrate Plus and Migrate Upgrade modules are used for.

One method of creating a custom Drupal-to-Drupal migration involves using the Migrate Upgrade module to generate a set of migration configuration entities that you can use as a starting point. Even if you're not going to use the generated output in the end, this is still an informative exercise as it allows you to see examples of various migration paths.

In this tutorial we'll:

• Use the Migrate Upgrade module's Drush commands to import Drupal core's migration templates
• Examine the generated configuration entities
• Use the Migrate Tools module's Drush commands to view a list of the individual migrations that make up our Drupal-to-Drupal migration

By the end of this tutorial, you should be able to use the Migrate Upgrade module to generate the migrations that Drupal core would use to migrate content, list those migrations, and inspect them individually.

If you want to modify the Drupal-to-Drupal migrations created by Migrate Upgrade you'll need to export the Migrate Plus configuration entities, convert the ones you want to customize to standard migration .yml files, and put them into a custom module. Then, you can make edits the YAML definition of the migration, and keep your customizations in Git.

We recommend creating a new module to house the code that makes up your custom Drupal-to-Drupal migration.

In this tutorial we'll:

• Create a new module
• Export the migration configuration entities generated by drush migrate-upgrade as YAML files
• Copy the files that represent the migrations we're interested in into our new module
• Customize the copied files

By the end of this tutorial you should have a new module that contains the starting migration YAML files for your custom migration.

As part of creating a custom Drupal-to-Drupal migration we want to limit the set of users that are migrated from our source site into our destination Drupal site. In this tutorial we'll:

• Extend the existing source plugin
• Alter the query that's used to select users from our source site
• Update our user migration to use the new source plugin

By the end of this tutorial you should be able to override the core source plugins used when migrating from prior versions of Drupal in order to gain more control over exactly what is migrated.

Every row returned, from every source, during the execution of a migration is passed through hook_migrate_prepare_row() and hook_migrate_MIGRATION_ID_prepare_row(). Using these two hooks we can augment our migration in a variety of different ways.

In this tutorial we'll:

• Discuss the use case for hook_migrate_prepare_row()
• Implement hook_migrate_prepare_row() and use it to skip all but a select list of fields during the field migration
• Implement hook_migrate_MIGRATION_ID_prepare_row() and use it to skip all but a select list of node types

By the end of this tutorial you should have a better understanding of when hook_migrate_prepare_row() might be useful when writing your own migration, as well as how to skip rows in a migration based on conditional logic.

Before we can learn to write a custom migration, we need some sample data and a destination site for that data.

In this tutorial we'll obtain some source data to work with and configure our Drupal destination site by creating the necessary content types and fields to accommodate the source data. Then we'll look at the data that we'll be importing and start to formulate a migration plan.

By the end of this tutorial you'll have some source data and an empty but configured destination Drupal site ready for data import.

Source plugins extract data from a source and return it as a set of rows representing an individual item to import and some additional information about the properties that make up that row.

Anyone writing a custom migration, or module developers who want to provide a migration path from their Drupal 6 or 7 module, will need to work with source plugins.

In this tutorial we'll talk about the role that source plugins fulfill and how they work. By the end of this tutorial you should be able to determine whether or not you need to write a source plugin for your migration.

This tutorial covers writing a custom source plugin that imports data from a MySQL database into Drupal nodes. After completing this tutorial you should understand how to write your own custom source plugin that can:

• Extract data from an SQL source
• Describe the various fields in the source data to the Migrate API for mapping
• Provide unique IDs for each row of imported data

By the end of this tutorial you should be able write a custom source plugin that uses an SQL data store as well as have a foundation for writing source plugins that extract data from any source that PHP can read.

Process plugins manipulate data during the transform phase of the ETL process while the data is being moved from the source to the destination. Drupal core provides a handful of common process plugins that can be used to perform the majority of data transformation tasks. If you need some functionality beyond what is already provided you can write your own custom process plugins.

In this tutorial we'll:

• Examine the role that process plugins fulfill
• Understand the processing pipeline
• List the existing process plugins in Drupal core and what each one does
• Better understand when you might need to write your own process plugin

By the end of this tutorial you should be able to explain what process plugins do, and understand how you'll make use of them in your own migration.

This tutorial covers writing a custom process plugin that you can use to manipulate the value of any field during the process (or transform) phase of a migration. Process plugins take an individual field value provided by a source plugin, and perform transformations on that data before passing it along to the load phase.

In this tutorial we'll write a process plugin that can either uppercase an entire string or the first letter of each word in the string depending on configuration.

By the end of this tutorial you should know how to start writing your own process plugins.

Destination plugins handle the load phase of the ETL (Extract, Transform, Load) process and are responsible for saving new data as Drupal content or configuration.

In this tutorial, we'll:

• Examine the role that destination plugins fulfill
• Learn about existing destination plugins
• Better understand when you might need to write your own destination plugin

By the end of this tutorial, you should be able to explain what destination plugins does and understand how you'll make use of them in your own migration.

Migration plugins are the glue that binds a source, a destination, and multiple process plugins together to move data from one place to another. Often referred to as migration templates, or simply migrations, migration plugins are YAML files that explain to Drupal where to get the data, how to process it, and where to save the resulting object.

Source, process, and destination plugins do the heavy lifting in each phase of the ETL process in a custom migration. We need to choose which plugins we want to use for each phase, as well as map fields from our source data to fields at our destination. A migration YAML file glues it all together and gives it a unique name that we can use to run it.

In this tutorial we'll:

• Determine what information we're going to move, and where we're going to move it to
• Install Migrate Plus and Migrate Tools which we'll use to run our custom migration
• Write a custom migration plugin (configuration) YAML file that will work with Migrate Tools

By the end of this tutorial you should be able to write a custom migration YAML file and understand how to choose the source, destination, and process plugins that will do the work.

As of right now, the most reliable way to run custom migrations is using Drush. Depending on the version of Drush you're using you may also need the Migrate Tools module. In this tutorial we'll walk through using Drush to run a custom migration, as well as the other commands that can be used to manage the execution of migrations.

By the end of this tutorial you should know how to run your custom migrations.