I was recently given the responsibility to migrate exisiting data from a legacy site developed with .NET to a site powered by ATG. While this kind of job is always quite challenging, I started looking at migrating the user data first. Both the old and the new databases were in MS-SQL server and hence decided that simple SQL select from remote and then insert to local was the best strategy. The requirement was to just migrate the basic user information and their contact information but I still faced the following issues:

1. Primary keys: How are table primary keys stored in old system. Primary key ids in ATG are mostly strings. Hence it will not work unless the ids have been changed to be of type integer or the old system had string ids. Once data is converted, make sure all the id generators are updated so that ATG no longer creates ids in the same space.
2. Password: How are passwords stored in current system. The default implementation in ATG stores password as MD5 hash. The password field will probably definitely need some kind of conversion.
3. Data conversion: How much data conversion will be needed e.g. a conversion function will be necessary for each of these situations:
• The gender fields are stored in ATG as integer bytes while old system could have this field stored as text.
• The country could be stored with the long name or a short two char like GB.
• Column sizes could be different and hence default column sizes in ATG might need increasing.
4. Joins: How much joins are required. Understand the current DB model and then ATG user profile data model. ATG user data model involves many tables but most of them are ATG specific.
5. Data integrity: The current system may not have any constraints or the contraints in place may not be similar to what ATG demands. Hence data clean up will be necessary. ATG does have all kinds of constraints .e.g. .login name has to be unique.
6. Additional tables: Additional rows will need to be added to various tables just to keep ATG happy. I found that in addition to dps_user and dcs_user tables, empty rows will be also needed in dcs_user_catalog and dcs_user_wishlist tables.

Looking at the complexity and time involved just to migrate the users, it is probably advisable not to migrate order information unless there is enough time and budget allocated for the job.