If you are using a generic module as a backbone for all of your migrations, this section should help you set things up properly. Any time a user creates their own content type, you will need to create a separate custom class to import that type. Here is the structure of a generic module, with an extra file for custom content:


 - Includes all class declarations, extending the abstract class, which extends from DrupalNode6Migration. Any time you need to manipulate the data for all content types (using prepareRow(), for example), you should do that here.


 - Includes all migration registrations for classes specified in node.inc


- Includes dependencies and files to include (only include the previous two files)


- This file will contain both the custom classes and their respective registrations. You should change the prefix “dept” to the name of the department you are running migrations for. It would be a good idea to add the databases for that department in the comments at the beginning of the file as well. This is the class where you set the source database and Organic Group you are migrating to.


- This file contains all of your configuration settings and common arguments, such as which database to run migrations from and which Organic Group to assign to imported content. This is where you will call registration function from a file that contains custom content if you have one.


- If you are migrating multiple source databases into a single destination, you will need a script that clears the tables that keep track of migrated content. Please note that you cannot roll back the migrations once you do this. For more information, jump to the section titled Migrating from Multiple Sources to a Single Destination.