D7 to D8 Upgrade Looking for Non-Existing D6 Tables

Not sure if you're still having this issue. I ran into the exact same issue migrating from D7 to 8.5.0 last week.

I found that I had apparently run drush migrate-upgrade twice, and this had caused it for me. There must be something about that command that, if it has already run, goes back and looks for more stuff to migrate ... even if there's nothing else to migrate.

The larger problem here is that any time you run drush migrate-status without specifying a --group, it checks for all migrations that are known to Drupal. If migrate_drupal module is enabled, then all of the D6 and D7 migrations that are defined in that module are known to Drupal, whether or not they are applicable to the current site.

Unless I'm mistaken, the easiest way to solve this problem would be to separate migrate_drupal into two different submodules for D6 migrations and D7 migrations so that they could be enabled individually. I have trouble imagining a realistic case study where someone would want to import from both a D6 and a D7 site, and yet that is the default configuration.

Unfortunately I'm not ambitious enough to attempt to separate the module and offer a patch. I leave that to someone who has a better understanding of how the module works.

The migrations can be identified by the migration_tags (not groups). The current tags are 'Drupal 6', 'Drupal 7', 'Configuration' and 'Content'. So, commands like drush ms --tag="Drupal 6 should work to limit the output.

Yes, when Migrate Drupal is enable all the available migrations are discovered. The idea of separating migrate_drupal into two modules is interesting but at least one thing that makes that not attractive is that some migrations are valid for both Drupal 6 and Drupal 7.

@quietone thanks for the tip.

I ran into this for a D6 site. This solves the command line UX output ./vendor/bin/drush migrate:status --tag="Drupal 6" which is great.

What I don't understand is why migrate can list the right migrations when using the tag (shared D6/7 migrations) but still lists items for the wrong version

I see

  Default (default)   d6_url_alias  Importing   87388    22673      64715
...
  Default (default)   d7_url_alias  Idle        87388    0          87388

which seems a bug to me as migration found my D6 database.

Looks like this has been resolved. The way core finds all the migrations is working as designed.

The solution to limiting the output is to use the --tag option on the migrate-status command.

I came across this issue while trying to get rid of the annoying D6 migration error messages on a D7->D8 upgrade. In the end I got rid of them by altering out the D6 migrations, like this:

function hook_migration_plugins_alter(array &$migrations) {
  foreach ($migrations as $key => $migration) {
    if (substr($key, 0, 3) === 'd6_') {
      unset($migrations[$key]);
    }
  }
}

So this means it still is an issue right?

Sorry, as stated in #9 core is working as designed.

The typical way to ignore those messages is to use the filtering options on the `drush ms` command. The solution in #10 will work as well.