Migrate in Drupal 8

There is a proposal to use an API based on the Migrate module for major core version upgrades starting with Drupal 8 (http://drupal.org/node/1052692). The API is, of course, at its root a general-purpose Import API, with applications beyond just doing upgrades. This session is to discuss what form the Drupal 8 Migrate/Import API should take, and how we will take concrete steps towards implementing it.

Room: 
Time slot: 
Track: 
Coding & Development

Comments

A few random thoughts, following today's Symfony presentation:

1. Rather than port the Migrate code as it is to Drupal 8, we should be designing an Import API with one eye on the best practices and patterns of Symfony, and figuring out how to implement the best aspects of Migrate in a consistent way that will fit in the new Drupal/Symfony world. E.g., can our current prepare/prepareRow/complete methods become event listeners?

2. So, we should identify what the best parts of Migrate are - the things that do the most to help manage migration processes. E.g., the map table - maintaining the relationship between source and destination objects.

3. We need expertise in Symfony to do this. Who in the Migrate-aware community has it? How do the rest of us get it?

My comments are perhaps at a bit too general a level to be added to the Google doc, but wanted to post something, in the event it sparks something.

First of all, Mike, I wanted to thank you for all your work in Migrate. It's amazing.

Regarding symfony: Do we really think Drupal is going to head in this direction? If so, Drupal will be developing into an application server rather than a php application brokered via a web server. I was not sure, from the sessions I went to, whether the community really was ready to rally behind it. Nevertheless, it might be good to engineer the work with a view towards these specifics of implementation being pluggable, so we can quickly adapt to whichever direction the community takes.

One of the very useful features of migrate is not just the migrate map tables, but the reports of source fields and destination fields: in essence, the project management aspects of the module. This is great stuff and could be very useful for generating a "readyness report" when migrating to Drupal 8. There could be a list of things that cannot yet be migrated due to lack of support etc, so you could get an overview of whether you're ready to upgrade or not.

As I mentioned in the BoF, one of the things that concerns me is a conceptual one: Is an upgrade path something that a maintainer should take responsibility for, or not? If we are having this discussion because upgrades are broken due to lack of maintainer focus on that, then it seems like the answer is to find a way to force developers to create sane upgrade paths. One example would be how drupal handles security issues. If a maintainer doesn't respond to a security issue for a certain period of time, the module is blocked from being downloaded, and the project is set into a limbo state, until the issue has been addressed. Perhaps the issue with broken upgrades is a governance issue rather than a technical one.

My concern with forcing each user/site-maintainer to have to take responsibility for how their D6 or D7 site upgrades, is that introduce a HUGE upgrade barrier for Drupal users. Which means that more and more users will continue to sit on old Drupal installations. Many Drupal users simply don't have the resources to create a migration of all their data. It's not an easy process, and requires a lot of experience with data (and a lot of non-trivial coding) to implement.

Thanks again for leading the conversation.

Colorado mountains