Tasks to deprecate Migrate Drupal

I feel like there's another issue to discuss this, but putting here for now.

We need to decide when to do this, IMO it should be something like this:

It makes sense to support the Drupal 7 migrations in core until Drupal 7 is EOL, but for as short a time as possible after that date. That way supported Drupal 7 sites can migrate to a supported version of core, but unsupported Drupal 7 sites will eventually need to rely on the contrib module.

Therefore, if the Drupal 7 EOL date falls within the support cycle for Drupal 10, we should deprecate migrate_drupal in Drupal 10 for removal in Drupal 11.

Migrate Drupal isn't just for migrating from old sites. It's really useful for doing data migrations *within* a site. I've used it for things like migrating box entities to paragraphs, for instance.

@joachim are you using migrate_drupal to do in-site migrations or just migrate? This issue is only about migrate_drupal. If so, which bits of migrate_drupal are you using? If there's stuff that's generically useful, then we ought to be moving that to migrate anyway I think - migrate_drupal is only supposed to be for d6 and d7.

I use \Drupal\migrate_drupal\Plugin\migrate\source\ContentEntity a lot!

OK yeah there is that and \Drupal\migrate_drupal\Plugin\migrate\source\d8\Config. That seems worth migrating to the migrate module since it's version-agnostic - or even if we moved them to contrib they shouldn't be in a d6/d7 migrate module that's going to eventually drop support.

There's been some discussion among the release managers about other options for how to remove Migrate Drupal and Migrate Drupal UI. There was no decision, just knocking around ideas.

So, I am tagging this to a full discussion can take place.

I think we need to discuss this in 📌 [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL Fixed and leave this issue for figuring out mechanics, leaving the tag on but will comment over there.

Postponing on the policy issue

I use \Drupal\migrate_drupal\Plugin\migrate\source\ContentEntity a lot!

Thanks for bringing this up, @joachim. I came here to ask that it be preserved too. It's fantastic for doing data transformations within a site. And I'd look forward to not having to enable all of migrate_drupal just to have access to it.

@joachim, @dcam:

Good news! We plan to keep the content_entity source plugin. In fact, 📌 Move content_entity source plugin to migrate module Active is currently RTBC.

@benjifisher Thanks for the update and link!

I think we should also re-implement the d8_config source plugin (see Comment #12 here). I added the child issue 📌 Move the d8_config source plugin to the migrate module Active .

Oops, postponed the wrong issue

It looks blocked on

- 📌 [policy no patch] Make it possible to mark plugins as deprecated Needs work
- 📌 Create a way to declare a plugin as deprecated Needs work

@andypost it's not blocked on either of those issues.

We can deprecate the entire migrate_drupal module for removal in 12.x and then remove it then, that will notify any site that has the module enabled.

Next step is 📌 Move the d8_config source plugin to the migrate module Active still.