The art of data migration is an interesting thing. Taking data from one application and transforming it to be data for another application sometimes feels like using parts for an old VW Bug to repair a new VW Bug.
No matter how smoothly the migration goes, you always seem to end up with parts left over from the old bug and parts missing from the new bug. You want to bring along all the old parts incase you missed something, so you find yourself checking both ends of the car to determine which end has the trunk so that you can dump the left over parts in it.
The trick to data migration is to determine the purpose of very field in every table for both applications. And then, just like in elementary school, draw lines between the fields that are the same in both places. Think of that as Steps one and two.
Step three is to determine what fields in the new database aren't being populated from the old database and then figure out what fields must be populated and how to populate them. This may mean some transformation of old data to make it fit (hopefully in a less dramatic fashion than cramming a square peg into a round hole.) Some fields may have to have their values fabricated. For example, if you must know when a record was created under your new data structure and you don't have that under the old structure, you're gonna need to make up a date.
Step four is to find a home for the data from the old system that doesn't have a place in the new system. This is most often accomplished through the use of note fields. For a recent data migration I did, I actually reproduced the clients entire former interface in the notes for the new interface because the fields were so dramatically different.