Clean-up of Database after Migration from Drupal 7.x

[rbargerhuff]

Hello,

@smaiorana and I are on the verge of migrating a fully functional Drupal 7.x site to Backdrop 1.x. We are in the final stages and we have noticed that after the migration is complete, there is data and tables left over in our migrated database from modules that were in Drupal 7.x and have since been removed or merged into Backdrop 1.x.

For example, admin_menu was replaced by admin_bar however there is no clean-up.

The following is a list of modules with lingering data and data tables:

• admin_menu
• admin_menu_toolbar
• ctools
• features
• fe_block
• ftools
• help
• jquery_update
• label_help
• media
• module_filter
• overlay
• page_manager
• panels
• panels_style_collapsible
• rdf
• statistics

What my colleague and I have been doing to take care of this is to create stub modules that represent the Drupal 7.x modules. We have been combing through these modules for specific hooks both in the .module and .install files and carryng that logic over to the respective stub module.

Here are the hooks we have been looking out for:

• Implements install/uninstall hooks that dictate logic other than status messages
• Implements hook_schema().
• Implements hook_field_schema().
• Implements a hook_permission().
• Implements a hook_node_grants().

After the stub module is created, we have a hook_update_N in an install file of a module responsible for carrying out important steps during the migration process.

function portal_migrate_update_1014() {
  $modules = [
    'admin_menu', 'admin_menu_toolbar',
    'ctools',
    'features',
    'fe_block',
    'ftools',
    'help',
    'jquery_update'.
    'label_help',
    'media'.
    'module_filter',
    'overlay',
    'page_manager',
    'panels',
    'panels_style_collapsible',
    'rdf',
    'statistics',
  ];

  module_disable($modules);
  backdrop_uninstall_modules($modules);

  // Get rid of the directory containing all stubbed modules.
  $modulePath = BACKDROP_ROOT . '/modules/stubbed';
  file_unmanaged_delete_recursive($modulePath);

  // Disable any modules in the database that are not core compatible
 // or no longer exist.
  update_fix_compatibility();
}

I would like to understand the reasoning as to why Backdrop during the migrate process does not include this clean-up and if Backdrop should carry out this clean-up. Our stance is that Backdrop should carry out this clean-up but we understand if this is a scope issue and cleaning up these modules are outside the scope of Backdrop CMS.

Cheers!

[argiepiano]

@rbargerhuff these are great points, but please notice that some of those tables are created by contrib modules, and other tables are by core modules that don't exist in Backdrop. The directions for upgrlading actually recommend that you disable and uninstall those modules before proceeding to the upgrade. That will, by itself, take care of removing those unused tables (I haven't check all of them, but the majority seem to be taken care of in that step).

[rbargerhuff]

@rbargerhuff these are great points, but please notice that some of those tables are created by contrib modules, and other tables are by core modules that don't exist in Backdrop. The directions for upgrlading actually recommend that you disable and uninstall those modules before proceeding to the upgrade. That will, by itself, take care of removing those unused tables (I haven't check all of them, but the majority seem to be taken care of in that step).

Thank you @argiepiano ... seems like we may have missed that line of documentation. I'll talk it over with my colleague tomorrow morning.

[rbargerhuff]

This is a non-issue.