Any time a content type has custom fields (i.e. fields created by an administrator), you must tell the module how to map the data over. You do this using the Migration::addFieldMapping function. This function’s arguments are ordered counterintuitively; the source field is the second argument in the function and the destination field is the first argument. The call to Migration::addFieldMapping should look like:
$this->addFieldMapping('destination_field_name', 'source_field_name');
You can check the destination field names easily through the GUI. In the admin menu, go to Structure -> Content Types -> Type -> Manage Fields (where “Type” is the content type you are creating a class for). Custom fields are any field that is not Title, Body, URL Path Settings, or URL redirects. You may match the machine name directly for the destination fields. However, the source fields require more attention to detail. One does not simply copy the field name, as they did with the destination fields. To find the source field names, you have to connect to the source database through Drush. You need Aegir permissions to connect to the source database. The connection command will vary between source databases, but it should begin with a call to MySQL from Drush. You can switch databases inside MySQL by typing `use db`, where “db” is some other source database. Once you’ve found the correct database, you need to find the table of the content type for which you are mapping fields. This could either be in the node table or in content_type_foo, where “foo” is a content type. Once you find the correct table, use the SQL command desc table to get a list of the fields in that table. You will most likely see significantly more tables in the source than in the destination. Many tables will have the same name, but end in _attributes or _value. For these duplicate fields, truncate the last word and use the root of the field name inside your node.inc file. It may take some time to see which words need to be omitted for the fields to map correctly. You can always try a migration to test it and roll back if it doesn’t work properly.