I keep running into cases where commands (migrate-import, migrate-status) cannot find migrations. Usually I'm trying to run a migration, so I start with mi and then run ms when that is not found, which results in an empty result. This especially happens when using the same DB/code/config on a different host (develop locally, put everything on staging, then migrations not found).

I have tried diagnosing a bit and have noticed:

  • All of the modules necessary are installed (migrate, migrate_tools, my migrate module, etc)
  • I have tried the service calls with code from #2832199 and #2795447 but the following is empty:
$manager = \Drupal::service('plugin.manager.migration');
$plugins = $manager->createInstances([]);
var_dump(array_keys($plugins));

This may be heavily related to the issues above, but I'm trying to assess if there is a way for me to get this working.

Drupal version: 8.2.6

Comments

rballou created an issue. See original summary.

mark_fullmer’s picture

@rballou, I seemed to be having the same problem you're describing using 8.2.x, and tried the same patches in the issues you reference. Ultimately, however, the problem was due to namespacing in my migrate module. Obviously, you might have that all correct, but here are a few things to double-check:

1. Do you have the migration group defined in a .yml file in YOURMODULE/config/install/migrate_plus.migration_group.GROUPNAME.yml ?
2. Do you have the Plugin ID defined in docblock comments in your plugin, and does that match what is being referenced in your corresponding migration .yml file(s)?
3. Download and enable one of the migration examples from https://github.com/wunderkraut/migrate_source_example . Does it work?

#3, especially, should help determine whether this is an issue with your migration module or an external issue.

bkosborne’s picture

This will happen to me occasionally as well. If I ever figure out why I'll post back.

mikeryan’s picture

Version: 8.x-3.0-beta1 » 8.x-4.x-dev
Status: Active » Closed (duplicate)

I believe this should be addressed by #2752335: Properly integrate configuration-entity-based migrations with the core plugin manager and #2795447: Use the core plugin manager. If any one sees this problem with the current 8.x-4.x-dev releases (or later) of migrate_plus and migrate_tools, please reopen this with details.

ryrye’s picture

Status: Closed (duplicate) » Active

This issue is still present in 8.x-4.x-dev and 8.x-4.5

Under similar circumstances as OP, on my staging I'm getting "No migrations found" for some migrations, while they worked fine on local development environment. Some migrations do work, but others give this "No migrations found". They import without complaint using drush cim, but when I try to run the migration using drush mim, I get this error.

I noticed that all of the ones that aren't working are related to migrating field_collections to paragraphs entities, or paragraphs to paragraphs (d7 to d8). They did work in previous tests on my local development environment.

sseto’s picture

@ryrye

I'm having the same issues with field_collections to paragraphs too. It was working last week, now I'm getting [error] No migrations found.

Were you able to find a solution?

Thanks!

dianacastillo’s picture

this happens when the connection to the database you are tryng to migrate from is not properly set up in your settings.php file

malcomio’s picture

I found this issue happening when my migration had an (undeclared) dependency on migrate_source_csv, but that module was not enabled.

After enabling migrate_source_csv, the migration was visible when running migrate:status

cperez1975’s picture

HI!
I'm working with Drupal 8.9.13, everything goes fine in local but when i have installed my custom migration module in the server only a few of the migrations registered shows.
The migrate database configuration is right. I've got two migration groups, one shows complete but the other one only gets five migrations from more of 200.
Please any help will be really aprecciated!
Best regards

cperez1975’s picture

Ok, I just find that they are in the admin/structure/migrate but not show in drush migrate-status... any suggestion?
Best regards

realgiucas’s picture

I got the same situation.
In my case I had the source d7 db not completely imported.

sjaxon’s picture

I kept running into the 'no migrations found'.

I tried:

drush cache:rebuild

The .yml file was found.

nginex’s picture

I noticed that If you use shared_configuration in the migrate group and your migrations in MYMODULE/migrations then shared_configuration will not work and if it contained source then you will not see migrations when running drush ms.

So please make sure your migration has successful connection to the source.

asherry’s picture

For what it's worth, nginex in comment #13 was right in my case. The database was actually accessible but, (I'm using lando), because I did a lando destroy && lando start, there were no tables in the migration database.

Once I added the actual tables, then all the migrations showed up correctly.

anybody’s picture

Version: 8.x-4.x-dev » 6.0.x-dev
Status: Active » Postponed (maintainer needs more info)

Updating to latest version 6.0x. where development happens, but also setting this Postponed (maintainer needs more info) as from the comments I think we can't be sure that the root cause in within this module at all?

There can be various (core & contrib) reasons for this and I think it will be hard to solve this without clear information how this can be reproduced.

tvb’s picture

Chiming in with my case:

If you use a custom source plugin, make sure source_module in the annotation is set to an enabled module in the source site.

drush migrate:import <migration_id> will just report "No migrations found", while log messages contains a message "Migration did not meet the requirements." with mention of the offending source_module.

theodorosploumis’s picture

Had the same issue when installed the taxonomy_machine_name module.

mallory99’s picture

I ran into this issue today, with taxonomy term migrations in a custom module. CSV term migrations (in the same module) worked normally for a different vocabulary. The migration ids were correct and cache rebuilding made no difference.

On a hunch, I ran drush migrate:upgrade --legacy-db-key=migrate --legacy-root=http://[installation] --configure-only. After doing this, suddenly the rejected migrations ran.