[Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL

I think moving to contrib for Drupal 11 is a good plan. See comment in #3114899: Future of migrate in core in a post Drupal 7 world for reasoning.

However also note #3315257-9: [meta] Tasks to deprecate Migrate Drupal and downwards - we ship Drupal 8+ entity and config source plugins in migrate_drupal, and I think we could reasonably support these in core, maybe in migrate module itself?

I agree as a Drupal core product manager that moving to contrib in Drupal 11 would be good.

It's my understanding from @quietone that the current consensus among the migrate maintainers is to keep the full set of functionality in Drupal 11 core, because it would be a lot of work to move it to contrib now and there are still hundreds of thousands of sites that will potentially want to migrate from Drupal 7 to Drupal 11.

There are three issues discussing this now, I think the last time I left a comment was #3114899-14: Future of migrate in core in a post Drupal 7 world, at that time talking about removal in Drupal 11.

If we don't remove anything in Drupal 11 but defer until Drupal 12 (which I'm fine with), I personally think we could do the following:

1. Keep the migrate destinations, and the Drupal 8+ sources (which are currently in migrate_drupal and would need to be relocated) in core migrate module / core modules. If we want to think about removing those, it should be its own issue with its own decisions, not linked to the Drupal 6 and 7 migrations at all. For example groups 2 to 3 requires an in-site migration and there are plenty of other use-cases.

2. Deprecate the Drupal 6 and Drupal 7 sources for removal in Drupal 12 with no replacement. If you still need to migrate from Drupal 6 or 7 in 2029 or past 2030, then you'd have to migrate from five years out of support Drupal 7 to 1 year out of support Drupal 11 then get onto a supported version from there, or do a custom migration. We're literally talking an entire 5-6 year major release cycle (minus one month) beyond Drupal 7's EOL for migration support which is a very, very long time.

3. migrate_drupal then goes from deprecated in Drupal 11 to obsolete in Drupal 12.

4. migrate_drupal_ui also goes from deprecated in Drupal 11 to obsolete in Drupal 12.

#7 is right in line with my hopes and dreams. If we deprecate in 11 and remove in 12, I don't feel any obligation to proved a contrib version of migrate Drupal. Anybody in the community is welcome to put one together, but it would not be a responsibility that we as migration system maintainers would take on directly.

This is also inline with the maintainer consensus at the last maintainer video, though I'll let everybody else weigh in, now that it's written out like this.

+1 on #7. I really wasn't looking forward to all the extra work needed to remove migrate from core in another way then just removing it.

Updated the issue summary with a bit more verbiage. I'm marking this RTBC. I think it would be a good idea to time the deprecation for 11.1 (or commit it to 11.2 very early if for some reason it doesn't land in 11.x), so that we can publish the change record and potentially announce it around the same time as the Drupal 7 EOL. There will be some things to move out of migrate_drupal/migrate_drupal_ui into core, so it will make sure that work doesn't end up blocking the Drupal 12 release then.

+1 on the RTBC

The solution does not specifically mention the process plugins and destination plugins in core modules outside of migrate.

I think we can make some of these decisions as we do the deprecations. I think the destinations can stay where they are for the most part. They are appropriate plugins for the remaining migrate API, and are useful for anyone using migrate to import data from any source. The process plugins should be looked at on a case by case basis, but if they are generally useful and specific to the module in question then they are fine to stay. If they are very specific to converting something from a d7 format to a d8+ format, they can be deprecated along with the migrate_drupal modules. (I think most of the process plugins that aren't in migrate core will fall into this category, but there may be a few worth keeping)

I tweaked the wording about destinations a bit to indicated that module specific destinations can stay where they are and added a note about deprecating field and process plugins outside of migrate_drupal that are migrate_drupal specific. Leaving RTBC as I think this is just clarifying what we've already decided, and obviously if we deprecate migrate_drupal and it's migrate field plugin manager we would have to deprecate the related plugins throughout core too.

I am a core product manager.

I agree with deprecating Drupal 6 and 7 migrations to modern Drupal in Drupal 11 and removing the code for these in Drupal 12 without replacement / contrib placement given the age of the code. I think if someone really needs it (eg. folks that work on extending Drupal 7 support one way or another would still need it in 2028), they can do it. But I agree we don't need to officially mandate or support a contrib solution for this. Removing the review tag.

BTW I also agree that whether migrate's destination plugins and APIs should also remain in core is a separate issue that also needs to be discussed. My feeling is that without the Drupal 6/7 use case, it will be far from an 80% module. It is also not in danger of having competing solutions in contrib (eg. more similar to webform than to layout builder / paragraphs / Gutenberg), so I don't see dangers of moving migrate's APIs and module too into contrib, but once again, I agree that would be its own issue.

The subsystem maintainers all agree on this plan, so I am removing the tag for that.

I agree in a framework manager capacity. The key tenet here is moving the destination/source plugins into migrate module. +1 from me.

Doubling/tripling up as a framework/release manager and also the person that RTBCed this, but I think @larowlan and me is enough to remove the tag for framework manager review.