Data Migration is one of the most time consuming and risky ventures in a system implementation. There are many misconceptions about this process (see article published in Technology Evaluation Centers, Inc. published February 4, 2007) that need to be continually addressed in order for implementation teams to understand the venture upon which they are embarking.

As older system begin to outlive their usefulness in an organization, there is a growth in the use of spreadsheets and ancillary systems. This is primarily due to older systems not being able to support the needs of current business processes. As a result, many organizations choose to use methods to record and manage this information in the form of spreadsheets or database software systems such as Access, Filemaker, Goldmine and others. This will meet their immediate business needs and will work fairly well until all the data must be migrated over to a new enterprise-wide system.

The primary problem that organizations will face using multiple data sources prior to a migration is the inability (primarily due to human error) to keep the two sources in sync with one another. One data source will usually be maintained to a higher degree of accuracy than the other. The better maintained system will be the one that provides additional information that is more business useful for the functional area that is tasked with maintaining the data.

When embarking on a data migration project, the problems multiply exponentially. Simple items, such as a customer number maybe entered into each system, slightly differently. For example, one system may not allow dashes (-), slashes (/), spaces or other odd characters that may be found in a customer number. When acquiring a database system or a spreadsheet, these limitations may not be an issue. But when the data must be merged and migrated into a new system, these numbers will not match and as a result will not be migrated.

Another type of problem that is frequently encountered is that there may not be a one-for-one relationship of data between the two systems. For example, the information may be in one system for the total amount of a customer order, whereas in the other system, the information is entered at higher level of detail such as each of the line items on the customer order. Problems will develop when the total amounts of the customer orders do not match exactly, thus kicking the entire item out of the migration process.

When the organizations decide to use these ancillary systems, they must keep an eye to the future and ensure the information input into the system follows a standard protocol for both systems and be maintained to a high degree of data integrity. This will create a smoother path when transitioning to another system.