Migrate

Drupal 8 migration - all the modules

mikeryan — Fri, 20 Nov 2015 22:53:42 +0000

Drupal 8 migration - all the modules mikeryan Friday, November 20, 2015 - 04:53pm

Now that Drupal 8.0.0 is released, let's take a look at all the components of the Drupal migration ecosystem and where they stand now. To provide context to those familiar with migration under Drupal 7, I will show where the pieces came from. First, general migration support:

Feature	D7	D8	D8 status
Basic migration framework	migrate (contrib)	migrate (core), plus destination plugins in core modules	Experimental
General-purpose drush commands	migrate (contrib)	migrate_tools (contrib)	The most common commands (ms, mi, mr, etc.) are working
General-purpose UI	migrate_ui submodule of migrate (contrib)	migrate_tools (contrib)	Just basic display of migrations and their status so far
CSV source plugin	migrate (contrib)	migrate_source_csv (contrib)	Working
XML source plugins	migrate (contrib)	migrate_source_xml (contrib)	A basic initial implementation exists, still needs work
JSON source plugin	migrate (contrib)	migrate_source_json (contrib)	A basic initial implementation exists, still needs work
List source plugin	migrate (contrib)	migrate_plus (contrib)?	Currently assessing how to architect this in D8 - most likely will be helper classes or traits in migrate_plus
Other source plugins	migrate (contrib)	Contrib	To be implemented as needed, by the people who need them
Migration groups	migrate (contrib)	migrate_plus (contrib)	Hopefully we'll finally get this into core for 8.1
Basic programming examples	migrate_example submodule of migrate (contrib)	migrate_example submodule of migrate_plus (contrib)	Working but needs an image migration example
Advanced programming examples	migrate_example submodule of migrate (contrib)	migrate_example_advanced submodule of migrate_plus (contrib)	Skeletal at the moment
Migration support for contrib modules	Ideally in the contrib modules themselves - some legacy handlers are still in migrate_extras	Contrib	Each contrib module is responsible for implementing its own destination plugins (for general migrations), plus migrations and source plugins for migrations/upgrades from another Drupal site
Migration from manifest files (lists of migrations with configuration overrides)	N/A	migrate_manifest (contrib)	Only supports template-based migrations from SQL sources

And then, features specific to migrating from another Drupal site:

Feature	D7	D8	D8 status
Major Drupal version upgrade (drush command)	pm-update (in Drush itself)	migrate_upgrade (contrib)	Working - to be moved to Drush itself (hopefully by Drupal 8.1.0)
Major Drupal version upgrade (UI)	/update.php	migrate_upgrade (contrib)	Working - to be moved to Drupal core (hopefully by Drupal 8.1.0)
Framework for migration from Drupal 6 and 7.	migrate_d2d (contrib)	migrate_drupal (core), plus migrations and source/process plugins in core modules	Experimental. The D6 support is essentially complete; D7 is lacking support for some secondary core modules, file/image fields, etc.
Framework for migration from Drupal 5.	migrate_d2d (contrib)	migrate_drupal_d5 (contrib)	Very basic support for key core data (taxonomy, users, nodes). Not updated in a few months and probably needs rerolling for 8.0.0.
Framework for migration from Drupal 8	N/A	migrate_drupal_d8? (not yet created)	Planned. Most likely will be initially implemented in contrib, to be submitted to core in a later minor release.
Support for custom migrations from Drupal	migrate_d2d (contrib)	migrate_d2d (contrib)	Not yet begun

Notes on the statuses above:

The migration support in core is currently marked "Experimental". This means there are still some holes to fill (particularly for upgrading from Drupal 7), and still some leeway to make backwards-compatibility-breaking changes for Drupal 8.1.
I say "Working" rather than "Supported" for a few things above because A. All of these components are dependent on the core framework which is still subject to change, and B. To this point none of this has had substantial real-world testing, so there are likely significant issues still to be addressed.

So, you may be asking yourself "what can I do today, and what modules do I need to do it?"

I want to upgrade from Drupal 6 or 7 to Drupal 8

You can do this today with migrate_upgrade. As stated above, the Drupal 6 migration path for core modules is pretty much complete. If you're looking at upgrading from Drupal 7, review the meta issue for Drupal 7 migrations to see if any of the missing pieces are important to your site. See my previous blog posts for detailed run-throughs of performing the upgrade through the UI or with drush.

I want to implement an upgrade path for my contributed or custom module

Unfortunately, documentation is lacking at the moment to help module authors implement upgrade paths from previous Drupal versions - I hope to work with others on this (and also post to my blog) in the coming weeks. For today, the tl;dr is:

Contributed modules are no different from core modules when it comes to the upgrade path (with one small caveat below), so
Find the core module most similar to your module in terms of the kind of configuration and data it manages, and see how its upgrade path is implemented (specifically, look in its migration_templates and src/Plugin/migrate directories).

The one caveat is that for non-core modules, running the upgrade process through the UI will incorrectly report that no migration path is found for your module. This is due to the fact that currently there is no automated way to identify the source module for a migration, thus the UI is working from a hard-coded table of core migrations. This is a cosmetic issue only - your module's migration will still be run. I will also note that in terms of debugging your upgrade path, the drush migrate-upgrade command has a very handy --configure-only option, which runs the configuration portion of the upgrade (turning migration templates into migration configuration entities) without actually running the imports. When debugging a specific upgrade migration, I will use this option, then (with migrate_tools installed) import all the migrations previous to the one I'm testing. At this point I can do drush sql-dump >/tmp/backup.sql. It's much faster to test the migration, tweak it, and restore the backup for another try than it is to go all the way back to the beginning.

I want to perform a custom migration from Drupal

Ultimately, there should be tools like the migrate_d2d UI in Drupal 7 to enable you to customize what you're importing and how it's mapped into your Drupal 8 installation - but that's going to take some time. At this point, the simplest approach is to run the drush migrate-upgrade --configure-only command to generate the migration configuration for a straight upgrade, export that configuration to config/install in a custom module, and edit the migration .yml files to suit your needs.

I want to perform a custom migration from not-Drupal

You'll need the migrate_tools (drush commands and basic UI for running and managing migrations) and migrate_plus (provides group functionality migrate_tools needs, plus examples) modules. In migrate_plus, open up migrate_example/README.txt and it will guide you through the basics of implementing SQL-based migrations. It's simpler than you think! If you're importing from source data not in an SQL database, there are CSV, XML, and JSON source plugins available. It's still well worth going through migrate_example to understand the general structure of migrations - it's just that the configuration (and potential extension) of the source plugin will differ.

I want to help

Obviously, there's a lot left to do here, both in the core framework and in the contrib tools. Please, by all means, report any issues you find in the relevant issue queues, and feel free to submit patches to fix bugs or add additional features. At this stage, the best thing you can do (especially if you're not a developer) is test the upgrade path for your Drupal 6 or Drupal 7 site and report what you find. The diversity of Drupal sites in the wild is staggering - to get the upgrade path nailed down and fully supported in Drupal 8.1, we need a wide variety of sites to go through it.

Upgrading to Drupal 8 using Drush

mikeryan — Wed, 21 Oct 2015 23:37:00 +0000

Upgrading to Drupal 8 using Drush mikeryan Wednesday, October 21, 2015 - 06:37pm

So, perhaps you've been reading Upgrading to Drupal 8 using the UI and thinking "hey, what about us cool kids who use Drush for everything?". Or, maybe you just know drush is better than a UI for running long processes like migrations. Well, this blog post is for you... We do have drush commands for running and rolling back upgrades, currently in the migrate_upgrade module (but which should land in Drush itself by Drupal's 8.1 release at the latest). First off, for preparing a D8 site to run the upgrade process, we're just going to give the tl;dr version here - see the UI post for more context. ~/Sites/d8$ # Install Drupal using the minimal profile ~/Sites/d8$ drush si minimal --account-name=admin --account-pass=admin --db-url=mysql://user:pass@127.0.0.1/d8 -y You are about to DROP all tables in your 'd8' database. Do you want to continue? (y/n): y Starting Drupal installation. This takes a while. Consider using the --notify global option. Installation complete. User name: admin User password: admin Congratulations, you installed Drupal! ~/Sites/d8$ # Enable the D8 modules corresponding to each source module you want upgraded. ~/Sites/d8$ drush en -y book,comment,block_content,menu_link_content,menu_ui,path,search,taxonomy The following extensions will be enabled: book, comment, block_content, menu_link_content, menu_ui, path, search, taxonomy, link Do you really want to continue? (y/n): y ... ~/Sites/d8$ # Don't forget the rest of the field types. ~/Sites/d8$ drush en -y datetime,image,options The following extensions will be enabled: datetime, image, options Do you really want to continue? (y/n): y ... ~/Sites/d8$ # Get the Drupal Upgrade (machine name migrate_upgrade, for historical reasons) module. ~/Sites/d8$ drush dl migrate_upgrade Project migrate_upgrade (8.x-1.x) downloaded to /Users/mryan/Sites/d8//modules/contrib/migrate_upgrade. ~/Sites/d8$ # Enable it! ~/Sites/d8$ drush en -y migrate_upgrade The following extensions will be enabled: migrate_upgrade, migrate_drupal, migrate Do you really want to continue? (y/n): y migrate was enabled successfully. migrate_drupal was enabled successfully. migrate_upgrade was enabled successfully. The Drupal Upgrade module has been enabled. Proceed to the upgrade form. ~/Sites/d8$ # Make sure it'll look nice when we're done. ~/Sites/d8/modules/contrib/migrate_upgrade$ drush en -y bartik The following extensions will be enabled: bartik Do you really want to continue? (y/n): y bartik was enabled successfully. ~/Sites/d8$ # Back up your database first! ~/Sites/d8$ drush sql-dump >/tmp/d8-pre-upgrade.sql

Running the upgrade

OK, you've now got a vanilla Drupal 8 site ready to accept your Drupal 6 or Drupal 7 site data. It's now simply a matter of running the drush migrate-upgrade command, pointing it at your legacy database (or a copy thereof - it is not recommended to run directly against your production database) and at the source for your files (which may be scraped from your live website, or copied from a local directory): ~/Sites/d8$ drush migrate-upgrade --legacy-db-url=mysql://user:pass@127.0.0.1/d6_site_db --legacy-root=http://mikeryan.name Upgrading d6_book_settings Upgrading d6_date_formats Upgrading d6_dblog_settings Upgrading d6_file_settings Upgrading d6_imagecache_presets Upgrading d6_search_settings Upgrading d6_system_cron Upgrading d6_system_date Upgrading d6_system_file Upgrading d6_system_image ... Upgrading d6_node_revision__story Upgrading d6_node_revision__todo Upgrading d6_node_setting_promote Upgrading d6_node_setting_status Upgrading d6_node_setting_sticky Upgrading d6_taxonomy_vocabulary Upgrading d6_taxonomy_term Upgrading d6_vocabulary_field Upgrading d6_vocabulary_field_instance Upgrading d6_vocabulary_entity_display Upgrading d6_vocabulary_entity_form_display Upgrading d6_term_node__1 Upgrading d6_term_node__2 Upgrading d6_term_node_revision__1 Upgrading d6_term_node_revision__2 Upgrading d6_user_contact_settings Now, wasn't that easier than clicking through a bunch of forms? One other option to the migrate-upgrade command worth mentioning is --configure-only. The upgrade process has two distinct stages:

Configuration: the database credentials are used to read and analyze the source database. Given the modules enabled on the source side and on the destination side, the relevant migration templates are configured and saved as runnable migration configuration entities.
Import: The import() operation is run for the migration entities configured in the first stage.

So, if you pass the --configure-only option, only the configuration is performed and you're left with all the migrations you need, ready to run. The advantage of that is that you can use the migrate_tools module (part of the migrate_plus project, about which more in a future blog post) to selectively run the migrations: ~/Sites/d8$ drush migrate-status Group: default Status Total Imported Unprocessed Last imported block_content_type Idle 1 0 0 d6_book_settings Idle 1 0 0 d6_date_formats Idle 3 0 0 ... d6_upload Idle 2 0 0 d6_upload_entity_display Idle 5 0 0 d6_upload_entity_form_display Idle 5 0 0 d6_user_contact_settings Idle 683 0 0 ~/Sites/d8$ drush migrate-import d6_date_formats Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'd6_upload' Finally, if you choose to go back and try the upgrade again from scratch, you can rollback the full upgrade (as explained in the UI post, simple configuration changes will not be restored): ~/Sites/d8$ drush migrate-upgrade-rollback All migrations tagged as 'Drupal' will be rolled back. Are you sure? (y/n): y Rolling back d6_user_contact_settings Rolling back d6_upload_entity_form_display Rolling back d6_upload_entity_display Rolling back d6_upload ... Rolling back d6_file_settings Rolling back d6_dblog_settings Rolling back d6_date_formats Rolling back d6_book_settings Rolling back block_content_type Alternatively, to be sure you are returning completely to square one, you can restore your backup: ~/Sites/d8$ mysql -u user -p d8



How'd it go?

This is one part of the UI post worth repeating - the upgrade path in Drupal core for 8.0 is experimental, and we need your feedback to tighten it up and make it fully supported for 8.1. If you ran into any problems in upgrading your site, or have suggestions for improving the process, please share them:

If your problem or suggestion is specifically about the drush commands, please open an issue in the Drupal Upgrade issue queue (being sure to check if it's already been reported, of course).
	If you had error messages while the upgrade process was running, or something was not imported correctly into your site, please open an issue with the "migration system" component in the Drupal core issue queue (again, checking for previous reports).
If you're not sure where to report the issue, just pick one and don't sweat it - we'll move it if necessary. Thanks!


Tags

        Migrate
      

        Drupal
      


    Comments
    

        I followed the above process        
      
      
      
        Anonymous (not verified)

        Sunday, May 22, 2016 - 03:22pm  

      
    

    
      I followed the above process and it appeared to work, but some of my site layout and content were not migrated from my Drupal 7.43 DB to my {empty-except for base d8 install} D8 DB.
dforeman@stny.rr.com




  


        There are still a few holes        
      
      
      
        mikeryan

        Monday, May 23, 2016 - 08:33am  

      
    

    
      There are still a few holes in Drupal 7 migration - see https://www.drupal.org/node/2456259. If you have a problem which is not covered there, and you can't find">https://www.drupal.org/project/issues/drupal?text=&status=Open&prioriti… an existing issue covering your problem, please open">https://www.drupal.org/node/add/project-issue/drupal">open a new issue for your problem.




  


        thanks for this had to remove        
      
      
      
        Anonymous (not verified)

        Friday, June 3, 2016 - 10:14am  

      
    

    
      thanks for this had to remove all my extra user_roles for it to work no biggie can read these in 
one question though if your happy with the migration can the migrate tables be deleted ?




  


        When done, you can uninstall        
      
      
      
        mikeryan

        Friday, June 3, 2016 - 04:32pm  

      
    

    
      When done, you can uninstall the migrate* modules - the migrate_map and migrate_message tables aren't currently automatically dropped (see https://www.drupal.org/node/2713327), but you can drop them manually.




  


        Hey Mike, 
Hoping for a        
      
      
      
        Anonymous (not verified)

        Monday, June 13, 2016 - 05:05pm  

      
    

    
      Hey Mike, 
Hoping for a little direction or advice. I have to perform an upgrade from D6 to D8. The source site cranks out a lot of content, so I need to be able to go back and import updated content into the D8 site before taking it live. I had started this process back with Drupal 8.0, but it has now dragged on to this point.

Problem I'm seeing is that Drupal 8.1.2 no longer supports the UI, migrate_tools, or migrate_plus. I installed  migrate_upgrade 8.x-2.0-beta1 so that at least gives me the ability to run an initial migration.
Even if I start over with a fresh install of D8, and rebuild my views etc, I'll need to import newer content before I can push it to production.  If I simply run migrate-upgrade --update will that allow me to perform an update without wiping out what I already have migrated? Or do I need to come up with a different plan?
Thanks




  


        Comments on an old blog post        
      
      
      
        mikeryan

        Tuesday, June 14, 2016 - 09:16am  

      
    

    
      Comments on an old blog post aren't a great avenue for support questions - http://drupal.stackexchange.com/ will get you more visibility (I'm not the only one in the Drupalverse who knows something about migration, after all).
Problem I'm seeing is that Drupal 8.1.2 no longer supports the UI, migrate_tools, or migrate_plus. I installed migrate_upgrade 8.x-2.0-beta1 so that at least gives me the ability to run an initial migration.


Where are you seeing that? The UI is in core now, and migrate_tools and migrate_plus (at least the -dev releases) work fine. See http://mikeryan.name/blog/mikeryan/migration-update-for-drupal-8-1 for the 8.1.x status of the migration ecosystem (as of a couple months ago).
If I simply run migrate-upgrade --update will that allow me to perform an update without wiping out what I already have migrated


There is no --update flag on migrate-upgrade - if there were one that worked like migrate-import, it would completely update all the previously-imported content from the latest source data. Simply running migrate-upgrade again will import any new content.




  


        Comments on an old blog post        
      
      
      
        Anonymous (not verified)

        Tuesday, June 21, 2016 - 11:52am  

      
    

    
      
Comments on an old blog post aren't a great avenue for support questions 


Perhaps not - but you did respond quickly and gave me a kick in the right direction. So thank you for that.
I'm trying to migrate into a fresh Drupal 8 site, and am having some serious issues - most likely due to the way the Drupal 6 site was built. But I'll save those posts for the issue queue or stackexchange.
Thanks again



Upgrading to Drupal 8 using the UI
mikeryan — Wed, 21 Oct 2015 23:36:00 +0000
Upgrading to Drupal 8 using the UI
mikeryan
Wednesday, October 21, 2015 - 06:36pm
Now that the second Drupal 8 release candidate (RC2) is available (with a significant fix for those upgrading from Drupal 6), it's time to start planning for your upgrade from Drupal 6 or Drupal 7. As I previously wrote, the migration system is "experimental" in 8.0, and at this time (mid-October 2015) the tools for upgrading are in a contributed module, Drupal Upgrade. The plan is that the upgrade path will be fully supported in core for Drupal 8.1 - to reach that goal, however, we need the path to be tested on a wide variety of sites in the meantime. So, we encourage everyone with a Drupal 6 or Drupal 7 site to start testing the upgrade path today - you don't want Drupal 8.1 to come out and only then discover your site has some quirk that's not fully accounted for. Even better, you might fight the upgrade path works just fine for your site and you can upgrade in the Drupal 8.0 timeframe! The current documentation for performing your upgrade from Drupal 6 or 7 to Drupal 8 is on drupal.org - I'll walk through the process as it exists today, but should you be referring to this blog post after October 2015, be sure to review the official documentation for any changes. This post explains running the upgrade process through the Drupal 8 web interface - if you'd prefer to use Drush, please see Upgrading to Drupal 8 using Drush. 

Preparing your site for the upgrade

The first thing you need is a fresh Drupal 8 site. Installing the code base is too environment-specific to go through here, but it is recommended that you use the Minimal install profile to give yourself the most flexibility in your configuration (and the blankest slate on which to write your legacy data). Note that the Minimal profile installs the Stark theme by default - your first stop after installation will probably be Administration->Appearance to pick a more substantial theme (the screenshots below reflect Bartik). And speaking of screenshots, a reminder - the migration support in core is "experimental", but this UI is at an earlier stage of experimentation and is still undergoing significant UX work, so what you see below may not be exactly what you see when you try the process yourself. Now, it's important to understand that the upgrade process does not automatically enable modules on your Drupal 8 site - it will only perform upgrade operations for modules enabled on your source site when the destination module for that data is enabled in Drupal 8. So, at this point, be sure to enable all modules in Drupal 8 that you were using in your legacy site (plus any other Drupal 8 modules you're planning on using):  The contributed Drupal Upgrade module also needs to be installed and enabled on the Drupal 8 site. At Adminstration->Extend, click "Install new module":  Back to the Extend page, enable this module as well as the Migrate and Migrate Drupal modules it requires: 

Configuring and reviewing the upgrade

Have you proceeded? You should now see the following page:  Now is an excellent time to backup your Drupal 8 database - as we've said, the upgrade support is experimental, and the quickest way to return to square one if anything goes wrong is to restore your backup. If you've just created the Drupal 8 site and are working alone on it, there's no need for maintenance mode, which is a purely cautionary step. Continuing:  The new Drupal 8 site needs to have access to a copy of your existing site's database, as well as access to your files. If you have only a public files directory on your site, the upgrade process can pull them directly over the web; however, if you have a large volume of file data it will be more efficient to make a copy of the files directory directly on your D8 server (and this is necessary for private files). Note that Drupal 7 allows you to have separate public and private file directories - the ability to specify both of these through the UI has not been implemented as of this writing. Once you've entered the information for your existing site and clicked Review upgrade, the source database is analyzed and enabled modules with upgrade paths are aligned with the corresponding modules that are enabled in Drupal 8 (note this page is the most likely one to be redesigned in the very near future):  First, this page lists modules enabled on the source site which have no defined upgrade path. There are various reasons for a source module to be listed here:

The module simply has no content or configuration that needs to be individually migrated. For example, the Drupal 6 blog module simply defined a node (content) type of 'blog', and those blog nodes are being migrated via the node module's migrations, so the blog module does not need its own migration path.
	A migration path exists, but the destination module is not enabled (and perhaps, for contributed modules, not even present). For example, if I had not enabled 'book' in Drupal 8, it would have been listed here.
	There is configuration or content for the module that can and should be upgraded, the module is enabled, but the module has not implemented an upgrade path (you are most likely to see this situation with contributed modules still being ported to Drupal 8).
For now, you can simply proceed - the upgrade process is repeatable, so if you enable a destination module, or an existing module adds an upgrade path, returning to /upgrade and running the upgrade process again will pick up the new data. Lower on the page, the modules being upgraded are reported:  As you can see, there is not necessarily a one-to-one correspondence between the modules in your Drupal 6 or Drupal 7 site and the Drupal 8 modules that manage the same data. For example, custom blocks have been moved out of the block module into a new block_content module. At this point, clicking Perform upgrade will - surprise! - perform the upgrade:  At this point it's worth mentioning that internally the individual tasks that are run to perform the upgrade are called "migrations", and there may be multiple migrations involved in a given module's upgrade path, to handle different kinds of content and configuration managed by that module. The feedback is thus per-migration, not per-module. If all goes well, you are delivered to your home page:  which hopefully (allowing for theming) shows the same content as your old home page:  Details on the upgrade process are logged to the watchdog: 

Starting over

If everything you wanted to upgrade came over perfectly and there are no lagging modules to worry about, congratulations! If there's still more to do - a newly-installed contrib module with an upgrade path, a core module you skipped the first time, or for that matter new content added on your existing site which you want to pull over - you can rerun the upgrade process to pull over only things which were not previously imported. Or, if you're not happy with the results, you can start from scratch. First, return to the upgrade page (example.com/upgrade):  As you can see, you have two options. The Rerun option will run through much the same process as you did originally (skipping the prompt for credentials and file location, because it remembers that from the first time), and if any new content was added for modules you previously upgraded, or new upgrade paths are now available, those will be imported now. Rollback allows you to return to square one - mostly. It will delete all content that was imported, and it will also delete all the configuration entities that were created, but will not restore simple configuration. The distinction is:

Configuration entities are structured sets of configuration which may have multiple instances - for example, a field's configuration or a content type's configuration is a configuration entity. Because these are created by the upgrade process, they can be deleted by the rollback process.
	Simple configuration is singleton settings such as the site name - there is a single value without internal structure. For simple configuration, there is already a default value (or a custom value, if you have manually configured the site) before the upgrade is executed. Because the pre-upgrade values are not preserved (there is no revisioning of configuration), they cannot be restored when rolling back the upgrade.
If you want to be absolutely sure you're returning to a vanilla installation, you're best off restoring the backup you took before upgrading (you did do that backup, right?). If you had a lot of content processed by the upgrade process, you'll also find it much faster to restore that backup. That being said, when experimenting with the upgrade process with a modestly-sized site, you may find the rollback functionality helpful: 

How'd it go?

So, once again, the upgrade path in Drupal core for 8.0 is experimental, and the UI more so - we need your feedback to tighten them up and make them fully supported for 8.1. If you ran into any problems in upgrading your site, or have suggestions for improving the process, please share them:

If your problem or suggestion is specifically about the UI - the forms, the workflow, the messaging - then please open an issue in the Drupal Upgrade issue queue (being sure to check if it's already been reported, of course).
	If you had error messages while the upgrade process was running, or something was not imported correctly into your site, please open an issue with the "migration system" component in the Drupal core issue queue (again, checking for previous reports).
If you're not sure where to report the issue, just pick one and don't sweat it - we'll move it if necessary. Thanks!


Tags

        Migrate
      

        Drupal
      


    Comments
    

        Additional upgrades no longer        
      
      
      
        Anonymous (not verified)

        Tuesday, May 10, 2016 - 07:40am  

      
    

    
      Additional upgrades no longer supported in Drupal 8.1.1.
Drupal Upgrade

An upgrade has already been performed on this site. To perform a new migration, create a clean and empty new install of Drupal 8. Rollbacks and incremental migrations are not yet supported through the user interface. For more information, see the upgrading handbook.

Last upgrade: May 9, 2016 - 20:27




  


        See        
      
      
      
        mikeryan

        Tuesday, May 10, 2016 - 07:49am  

      
    

    
      See https://www.drupal.org/node/2687843




  


        migration of books and book        
      
      
      
        Anonymous (not verified)

        Monday, May 23, 2016 - 03:04am  

      
    

    
      migration of books and book pages
Hello,

when will it be possible to migrate books and book pages, please.
Thank you in advance for your kind answer

Michael




  


        You don't mention if you're        
      
      
      
        mikeryan

        Monday, May 23, 2016 - 08:29am  

      
    

    
      You don't mention if you're migrating from Drupal 6 or Drupal 7. Book hierarchies should work for Drupal 6 - for Drupal 7, while the book pages (which are simply normal nodes) should migrate, the book hierarchy is not yet done - see https://www.drupal.org/node/2409435.




  


        Sorry, I noticed only after        
      
      
      
        Anonymous (not verified)

        Wednesday, May 25, 2016 - 08:19am  

      
    

    
      Sorry, I noticed only after it was sent. I meant from 7 to 8.

Thanks for the answer and the link. I will stay tuned...




  



Update on migration in Drupal 7
mikeryan — Thu, 30 Jul 2015 15:38:33 +0000
Update on migration in Drupal 7
mikeryan
Thursday, July 30, 2015 - 10:38am
A quick update on where the migration-related modules I maintain on Drupal 7 (migrate, migrate_d2d, and wordpress_migrate) stand now, to help set people's expectations of the level of support they can expect in the issue queues. There are two main points:

I am now officially working full-time on migration in Drupal 8, for the time being (I'll have a blog post with details on that work shortly).
	I feel that the Drupal 7 migration modules are pretty much functionally complete.
The first means I don't have much time available for Drupal 7 work - I do try to have a weekly session to catch up on the issue queues (ideally Friday) but can't guarantee that will happen every week, or that I'll get all the way through the recent issues when it does. The second means that feature requests have a high bar to reach to be considered for acceptance. I've previously stated this for Migrate itself, but it applies to all three modules - feature requests are unlikely to get in without:

A justification that the feature is generally useful (and not just addressing a very narrow use case),
	Demonstration that the desired outcome is not achievable (at least without considerable effort) using existing functionality, and
	A patch (ideally reviewed & tested by the community).
I will continue to do my best to address bug reports and support requests on a weekly basis. Of course, we are part of an open-source community here - other people knowledgeable in Drupal migration are more than welcome to help with incoming questions. Thanks for your understanding.


Tags

        Migrate
      

        Drupal
      




Migration contribution catch-up plan
mikeryan — Fri, 03 Oct 2014 22:08:42 +0000
Migration contribution catch-up plan
mikeryan
Friday, October 3, 2014 - 05:08pm
Well, what with an increase in client work and a move halfway across the country (Somerville Mass to Murphysboro Illinois), I'm afraid I've fallen further behind on the issue queues for migrate, migrate_d2d, and wordpress_migrate. It's been a bit of struggle to triage the queues, so to somewhat automate the which-issue-to-work-on-next process, I'm reducing it to an algorithm (each step of which will be applied to migrate, migrate_d2d, and wordpress_migrate in that order).

Bug reports with patches (needs review, rtbc), oldest to newest
	Other bug reports, oldest to newest
	Other issues with patches (needs review, rtbc), oldest to newest
	Triage of support requests to make sure no bugs are lurking there
At that point, I plan on cutting release candidates for all three modules. Hopefully at that point I'll be able to start doing a better job of responding to new issues as they come in. Hard to say when I'll have a chance to review and respond to older support and feature requests, though, it'll depend on my workload (but of course I'm not the only one in the community capable of helping out with support requests - hint hint). Thank you. Edit: Let's keep track of where I am... I'll also note that not all issues will necessarily get committed/closed, there will be some triage as I go along and not everything will make the cut for Migrate 2.6 and the corresponding migrate_d2d/wordpress_migrate releases.

Bug reports with patches, migrate
	Bug reports with patches, migrate_d2d
	Bug reports with patches, wordpress_migrate
	Other active bug reports, migrate
	Other active bug reports, migrate_d2d
	Other active bug reports, wordpress_migrate
	Other issues with patches, migrate
	Other issues with patches, migrate_d2d
	Other issues with patches, wordpress_migrate
	Triage of support requests, migrate
	Triage of support requests, migrate_d2d
	Triage of support requests, wordpress_migrate


Tags

        Migrate
      

        Drupal
      


    Comments
    

        You'll see all the steps        
      
      
      
        mikeryan

        Thursday, November 20, 2014 - 09:23am  

      
    

    
      You'll see all the steps above are crossed out - we're oh so close now! I'm going to make one last full pass through each module in turn before releasing RCs of migrate and migrate_d2d, and a beta of wordpress_migrate (which has had significant refactoring that hasn't had a good shakeout in the community).




  


        Migrate 2.6 RC2 is out!        
      
      
      
        mikeryan

        Monday, November 24, 2014 - 12:05pm  

      
    

    
      Migrate">https://www.drupal.org/node/2381259">Migrate 2.6 RC2 is out!




  


        Migrate_d2d 2.1 RC1 is now        
      
      
      
        mikeryan

        Monday, December 15, 2014 - 11:46am  

      
    

    
      Migrate_d2d">https://www.drupal.org/node/2393633">Migrate_d2d 2.1 RC1 is now available.




  


        wordpress_migrate beta2 is        
      
      
      
        mikeryan

        Tuesday, December 16, 2014 - 10:39am  

      
    

    
      wordpress_migrate">https://www.drupal.org/node/2394251">wordpress_migrate beta2 is now available. I released this as a beta rather than a release candidate because of the significant refactoring since beta1, it needs more of a shake-out.
So, barring any major issues arising, Migrate 2.6 should be released by the end of the week. I had hoped to get migrate_d2d 2.1 out by Christmas, but I'm not sure that's enough time from the RC release. Per above, wordpress_migrate will take a little more time - hopefully an RC early in the new year and 2.3 release within a few weeks of that.