We have built a migration script which can pull in the info and data from the old system to the new.
Just now we have discovered an issue with the script, there is data that it’s not importing. This is because some fields dont marry up. For example, Profile Fields in the old system were dynamic. User Profile fields in the new system are also dynamic, but unless we create them during the import process, the data from the old system has nowhere to go in the new system. So we’re now going to create them, and load them during the import procedure.
This new fix will effectively fix 90% or editable product templates which hitherto have imported badly.
The downside is that at some future date, we would encourage you to move data over to their more sensible locations. For example, users addresses should be kept in the address book, and branch opening times should be stored on department data (instead of user data).
Working Process
Due to the nature of the old system, and the complexity of the database and code, it is apparently impossible to import only small parts of the data. The migration script has to run as a complete unit. During the running of the script, all data from the new system has to be empty.
The implication of this is that only the following are possible.
- You can see your data in the new system, STOP using the old system, then fix any problems in the new system, then go live. No ongoing orders or order history are lost. (Admin will have access to the old system for some weeks)
- You can see your data in the new system, continue using the old system, then fix any problems in the new system, then go live. Any orders made on the old system, while testing the new system, will be lost.
The better scenario outlined below is not possible:
You can see your data in the new system, continue using the old system, then fix any problems in the new system, then have ongoing and recent orders loaded in, STOP using the old system, then go live with the new system.
