Registering content types will be done in the .module file. Be sure to include module_load_include(‘inc’, ‘module_name’, ‘node’) at the beginning of your file to load your file. In order for content types to be visible to the module, they must be registered. This is done in the hook_register_migrations() function. This function should be called within hook_flush_caches(). In hook_register_migrations(), there must be an array called $common_arguments, which contains the source database connection (legacy) and the source version (6). Next, each content type must be registered. Every content type needs the following:


which are elements of $type_arguments, where “type” is the content type you are registering. You append $type_arguments to the $common_arguments array, and then you must register the content type with the following lines:

Migration::registerMigration('hr_migrateTypeMigration', $type_arguments['machine_name'], $type_arguments);

which will allow this migration to show up when you call `drush @alias ms` (migrate-status). Please note that you cannot run a migration without first creating a class for that content type, which defines any custom fields and also allows you to run functions to manipulate the data being imported before it is saved to the destination database.If you make a mistake with the registration process (via inconsistent naming conventions, forgetting to add the lines above, etc.) you will get an error that looks like this:

PHP Fatal error:  Cannot instantiate abstract class DrupalVersion in /var/aegir/platforms/7.24-prod-1.0.0/sites/all/modules/migrate_d2d/ on line 101 

which is extremely hard to debug. My advice is to start looking through your .module file to see if there are are inconsistencies with plurality in your registrations (which is, unfortunately, very easy to do since it often changes between the source and destination). For example, I got this error by typing “announcements” instead of “announcement” in one part of the module; it broke the entire thing. Make sure you’ve included Migration::registerMigration… as stated above. If you still cannot find the source of the problem, check this page. Another problem you may run into occurs when you try to interrupt a migration (using Ctrl+C, for example). You may see an error that says “There is already an active process on Type”, where “Type” is the migration that was interrupted. You can get around this by running `drush @alias migrate-deregister type`, which will deregister the type that is causing you trouble. Simply clear the cache using `drush @alias cc all` and everything should run smoothly again. I haven’t come across an instance where this didn’t work or where it caused problems with duplicate content, but I don’t necessarily trust this method to work 100% of the time; try not to interrupt migrations with Ctrl+C if you can help it. This is merely a quick fix, and if you know of a smoother way to roll back the migration to a usable point, by all means do so!