Generally speaking, a new software product will replace an old system and will need to replicate existing processes, whilst adding more value through functionality and usability enhancements.
One of the biggest tasks within the project is data migration, making sure that all of the data still needed for the future is kept appropriately in the new system, acting just like it did in the old. Some factors you should consider are;

1. How are we going to create the relationships in the old system so that one record is still associated with another? You should ensure that you have the appropriate fields to store old unique identifiers which can be mapped to for further imports. For example, if you have a data set of contacts and a data set of accounts but have not thought about storing the old unique identifier for the entities, how will you know which “Bob Smith” should relate to which account without guessing?
2. Knowing your data source. How will you identify what data is ‘old’ data and what data has been recorded through the new system?
3. What is the planned strategy for the release date? Running both systems in parallel could ease the pressure on migration tasks as only a sub set of the data may be needed for the release.
4. Do not underestimate the time needed to migrate old data. Large data migration jobs should be done outside of office hours if the system is associated with the organisation’s networks so that performance doesn’t decrease with network traffic.

As mentioned previously, you’d expect that a new software product enhances the current situation. This will inevitably introduce new controls/fields to old data that never existed before, however you need to keep your data set as consistent and clean as possible. To make this as simple as possible, you should be looking to identify business rules. A business rule is essentially a trend which has conditions for populating the data. If we look at an example considering point 2 in more detail, we could simply fulfil this by having a checkbox control on each record that is ticked if the record came from the old system. The business rule for this could be “If the record was created on or before ##/##/####, then OldSystem == true”.

By doing this you have been able to populate a data set without having to review every individual record in the system, and the same technique can be applied for a whole array of combinations, such as applying account sub-types to accounts when particular conditions are true.