Installing a new Enterprise Resource Planning (ERP) software package is not an easy task - managing change in an organization is always difficult.  One issue that needs to be addressed is the migration of the data from the old software package to the new software package.  This requires an understanding of both packages.  The data in your existing software package is valuable and should be migrated electronically rather than manual re-keying of data.  This article describes the methodology that we use to migrate the data from one system to another.

Whatever the environment, a successful data migration project to a new ERP solution depends on the following:

1. New system data structure definition - Access to the data structure definition for the data files of the system to be imported into. This is facilitated by having a relationship with either the software vendor’s implementation manager, database administrator (DBA) or the application’s developer where questions can be asked on what is necessary.  If that is not possible then file layout definitions would be helpful.

2. Existing system data structure definition - Access to the data dictionary for the data file(s) to be exported. In a Pick/MultiValue database such as Universe or D3, dictionaries of data files do not need to exist and if they do, they do not always match the actual data.  If the dictionary items are not maintained, the migration team would have to analyze the application’s update routines to properly populate the dictionary definitions. If the source code is not available then the migration team would analyze the data itself to properly populate the dictionary definitions.  Professional “life experiences” comes heavily into play in the last case.  It is important that data dictionaries be maintained and that there is someone on staff that knows the data files.

3. Physical characteristics of export file - Agreement as to the physical characteristics of the exports final product – in many cases this is just an understanding that the output file will be tab-delimited with target file field names heading the export file – and where the exported file be written to (the host’s file structure, a network share, etc.).

4. Data Mapping - This is simply the assignment of the one-to-one relationships between the two system’s files – e.g. CUST.NO to CUSTOMER_NUMBER, CUST.NAME to CUSTOMER_NAME, etc. Where direct relationships do not exist, business rules are defined to interpret the required information – examples include “default country code to USA if zip field is 5 or 9 numeric characters excluding dashes’, “if not defined, default terms code to N30”, etc.

5. Coding (Programming) – This is the final step and involves making the conversion as user friendly as possible.  This usually involves writing scripts or programs to do the actual conversion.  An example of what is possible is our recent project of exporting to Great Plains (which is SQL Server based).  The Great Plains implementation lead person used Great Plains’s import manager scripting tool to create scripts for the daily importing of the tab-delimited files into their application.  TRG automated a Daily Invoice export from a D3 Linux system to Great Plains accounting.  D3’s background manager runs the export program each day at 00:05, writing the export to the Linux file structure a few minutes later.  A script on the Great Plains server automatically FTPs the file to the Great Plains server and runs the import script.

A migration to a new ERP software package is a major change for an organization and the project needs to be properly managed.  Surveys have shown that over 50% of Information Technology (IT) fail or do not produce the anticipated results.  In a migration/conversion project, the people component is more critical than the technology component.  In a project of this type 80% of the success is based upon “why” to do it and 20% is based on “how” to do it.  Organization management commitment to the project is necessary for project success.  The “why” creates a sense of ownership of the people involved with the project.  There should be a project plan document that has clarity that the defined project team should follow.  The project team members should be committed to the project with few other responsibilities.  The team should plan for the best but expect the worst.  The team should realize that perception is more important than reality and the user’s perception is reality.  The team needs to solve problems while they are still small and not after they have become a monstrous problem.  As with most projects, communication is critical in the success of a project of this type.