Copying customers (only) from 1.3.9h to 1.5.1

Hi,

I have a store on 1.3.9h - and we're launching a new store, using 1.5.1.

The new store has a completely different design, template and nothing from the old 1.3.9h store is needed but the customer database.

The old store will be kept intact as that is still live and the products being sold on this old store is different from what will be sold on the new store - but we want to retain our customer base.

Would simply copying over the customer tables (address_book, customers_info, customers) from the old store's database which is 1.3.9h into the new stores database which is 1.5.1 be a problem - or would it be required that I do a database upgrade on a copy of the old store's database first, before I copy the data over?

yaseent:

Hi,

I have a store on 1.3.9h - and we're launching a new store, using 1.5.1.

The new store has a completely different design, template and nothing from the old 1.3.9h store is needed but the customer database.

The old store will be kept intact as that is still live and the products being sold on this old store is different from what will be sold on the new store - but we want to retain our customer base.

Would simply copying over the customer tables (address_book, customers_info, customers) from the old store's database which is 1.3.9h into the new stores database which is 1.5.1 be a problem - or would it be required that I do a database upgrade on a copy of the old store's database first, before I copy the data over?

Standard answer is to do the upgrade. However there is something to be said about what is desired to be kept for the business and the customers. There's more than just customers and there's more than justproducts in the database,there's also history in a way.

But for functionality, yaeh could basically just copy over the customer's database at leastthat way they will still be able to login.

mc12345678:

Standard answer is to do the upgrade. However there is something to be said about what is desired to be kept for the business and the customers. There's more than just customers and there's more than justproducts in the database,there's also history in a way.

But for functionality, yaeh could basically just copy over the customer's database at leastthat way they will still be able to login.

Hi mc12345678,

thanks for the response, and your help.

I was thinking maybe I should just do a database upgrade and use the same database - and what I can do is disable the products on the new store. That way customers can still see their order history no matter which site they log into.

What will be the consequences with regards to tables and other entries in the SQL that were put into the database by addon modules? Will the upgrade clean them out or will they be retained? I would prefer they be cleaned out so that I can install the addons again from fresh - and also some addons will not be included on the new site.

IMHO, the best thing to do is:

1. create a backup of the old site's database
2. upgrade old DB to latest version using zc_install
3. export address_book, customers, customers_info, orders, orders_products, orders_products_attributes, orders_products_downloads, orders_status_history and orders_total
4. DROP those tables in the new DB
5. import from #3 into your new database

The only thing you need to be careful about is any plugins on the new site that may have modified any of those tables (for example, FEC would add a few columns into customers and orders...).
No need to use the entire old database because you'll probably lose your configuration and settings and could actually make your life complicated down the road...

I've used this approach numerous times and it never failed... :smile:

balihr:

....
3. export address_book, customers, customers_info, orders, orders_products, orders_products_attributes, orders_products_downloads, orders_status_history and orders_total...

Yep, but bear in mind that the OP only wants customer data (no orders etc) as the new store will have completely different products.

balihr:

....The only thing you need to be careful about is any plugins on the new site that may have modified any of those tables (for example, FEC would add a few columns into customers and orders...)....

Simple way around this is to do the import before installing any plugins on the new site and get rid of any extra columns inherited from the old site.

frank18:

Yep, but bear in mind that the OP only wants customer data (no orders etc) as the new store will have completely different products.
OK, but still... These tables have nothing to do with the current products in the new catalog. These tables would be transferred for one purpose only - order history. Since none of the order history pages generate a link to the product page based on orders_products.products_id, I don't see a reason for not doing it.
One thing that comes to my mind is the Quick Re-Order Sidebox which would be broken (or better say confusing), but does anyone even use that anymore? :smile:

Of course, in case the OP doesn't want to keep their order history, he will simply skip all orders* tables. But, under the assumption he's transferring his customers with their consent (meaning it's not a purchased list or something like that), AND the old site is no loner being used, I believe order history would not hurt...

balihr:

IMHO, the best thing to do is:

1. create a backup of the old site's database
2. upgrade old DB to latest version using zc_install
3. export address_book, customers, customers_info, orders, orders_products, orders_products_attributes, orders_products_downloads, orders_status_history and orders_total
4. DROP those tables in the new DB
5. import from #3 into your new database

The only thing you need to be careful about is any plugins on the new site that may have modified any of those tables (for example, FEC would add a few columns into customers and orders...).
No need to use the entire old database because you'll probably lose your configuration and settings and could actually make your life complicated down the road...

I've used this approach numerous times and it never failed... :smile:

Hi balihr -

thanks so much for the response.

This is excellent information - it will seriously help me considering it's tried and tested.

Just a few more questions,

to upgrade the database, all that is required is the zc_install folder correct? I won't need to copy over the 1.5.1 files over the 1.3.9h files for purposes of just the database upgrade?

I took a look at my tables on 1.3.9h and just compared columns and so forth. I noticed that my order_totals included a variable "ot_insurance". This is a module I use and will use in the new store, this is the Optional Insurance module. I take it I should probably install this module into my new 1.5.1 before importing the selected tables?

I also noticed in my orders table - the shipping_module_code column has the customized shipping modules according to how I have renamed them - in this case I will need to first have those copied over (or re-created) before I should import the orders table - like in the case of the "ot_insurance" ?

I think to be safe I should also copy over the products and just disable them manually, there are only 300 or so products.

Please advise on the tables required for the products (I do not use attributes) - according to the WiKi, these are the tables I should definitely use:

 products
products_description
products_to_categories
categories
categories_description
manufacturers
manufacturers_info

yaseent:

to upgrade the database, all that is required is the zc_install folder correct? I won't need to copy over the 1.5.1 files over the 1.3.9h files for purposes of just the database upgrade?
I usually use any clean 1.5.1 install and just change the includes/configure.php file to use my old database. Then I run the zc_install from the 1.5.1 version and go to Upgrade Database.
There might be simpler ways to do it, but this is my routine and I stick with that.

I took a look at my tables on 1.3.9h and just compared columns and so forth. I noticed that my order_totals included a variable "ot_insurance". This is a module I use and will use in the new store, this is the Optional Insurance module. I take it I should probably install this module into my new 1.5.1 before importing the selected tables?
First of all, it's just COLUMNS you'd need to recreate, values are almost irrelevant. Keyword is almost. There might be some strange occurrences if you miss some values, but nothing that would break the site.
Since you'll be installing that module again, no worries.

I also noticed in my orders table - the shipping_module_code column has the customized shipping modules according to how I have renamed them - in this case I will need to first have those copied over (or re-created) before I should import the orders table - like in the case of the "ot_insurance" ?
Doesn't really matter - all the required information is stored in the same table and the module code is there for reference only - it's not really being utilized. So, when the customers open order history page, they will see the values that are stored in the orders table and it will display the shipping module's name which was used when the order was placed. Think about it - let's say you have Flat module installed and you rename the files to read "1st Class Express Shipping". Customer ABC will see that during checkout and place the order. 10 days later you rename the same module and now it reads "Snail Mail - Delivery within 60 days". Now, customer ABC returns to your site and goes to order history - they MUST see what they saw during checkout, not something you changed afterwards...
So, long story short - no, you don't need to reinstall all of your old shipping modules.

I think to be safe I should also copy over the products and just disable them manually, there are only 300 or so products.
Same answer as above - this information is already stored in the orders table so, unless you're using something like "Quick Reorder" or similar modules (basically, which check orders table and retrieve products_id and then generate a link to current product with that ID), you don't have to do this. Unless, of course, you want. If I were you, I wouldn't do it - why add anything to your catalog that you'll be skipping all the time...

[QOUTE]Please advise on the tables required for the products (I do not use attributes) - according to the WiKi, these are the tables I should definitely use:

 products
products_description
products_to_categories
categories
categories_description
manufacturers
manufacturers_info\[/QUOTE]

Yup, that's all you need if you don't use attributes.

G'luck! :smile:

P.S. Did I mention to create complete backups before doing any upgrades, exports, imports or anything? If not, well, I just did. :wink2:

balihr:

I usually use any clean 1.5.1 install and just change the includes/configure.php file to use my old database. Then I run the zc_install from the 1.5.1 version and go to Upgrade Database.
There might be simpler ways to do it, but this is my routine and I stick with that.

First of all, it's just COLUMNS you'd need to recreate, values are almost irrelevant. Keyword is almost. There might be some strange occurrences if you miss some values, but nothing that would break the site.
Since you'll be installing that module again, no worries.

Doesn't really matter - all the required information is stored in the same table and the module code is there for reference only - it's not really being utilized. So, when the customers open order history page, they will see the values that are stored in the orders table and it will display the shipping module's name which was used when the order was placed. Think about it - let's say you have Flat module installed and you rename the files to read "1st Class Express Shipping". Customer ABC will see that during checkout and place the order. 10 days later you rename the same module and now it reads "Snail Mail - Delivery within 60 days". Now, customer ABC returns to your site and goes to order history - they MUST see what they saw during checkout, not something you changed afterwards...
So, long story short - no, you don't need to reinstall all of your old shipping modules.

Same answer as above - this information is already stored in the orders table so, unless you're using something like "Quick Reorder" or similar modules (basically, which check orders table and retrieve products_id and then generate a link to current product with that ID), you don't have to do this. Unless, of course, you want. If I were you, I wouldn't do it - why add anything to your catalog that you'll be skipping all the time...

[QOUTE]Please advise on the tables required for the products (I do not use attributes) - according to the WiKi, these are the tables I should definitely use:

 products
products_description
products_to_categories
categories
categories_description
manufacturers
manufacturers_info

Hi balihr -

excellent :D

Thank you so much, I really appreciate it - your information has been extremely helpful :hug:

To retain ONLY the customer info, I'd do the following:

1. set up a separate new TEMPORARY site on the new version, do a brand new install, to a new database (using the same DB_PREFIX setting as the old site had)

2. export the old database

3. import the old database to the new temporary site's database

4. run zc_install on that new temporary site

5. now export just the tables related to customer details: customers, customers_info, address_book.
   Now, if you also have group-discount-prices set up, you'll want the group_pricing table as well.
   Reference: http://www.zen-cart.com/wiki/index.php/Developers_-_Database_Schema#Customer_Information

6. Now you've got the customer data available in a format suitable for the specific ZC version you upgraded to in step 4 above. So, if that format was 1.5.1 and later you decide you want to upgrade to 1.6.0, you'll need to set up a 1.5.1 site and import that data, and then upgrade that 1.5.1 site to 1.6.0 in order to upgrade that data. Basically repeating steps 1-5 all over again, but with a new set of versions.

Not recommended for someone not familiar with databases and tools like phpMyAdmin.

DrByte:

To retain ONLY the customer info, I'd do the following:

1. set up a separate new TEMPORARY site on the new version, do a brand new install, to a new database (using the same DB_PREFIX setting as the old site had)

2. export the old database

3. import the old database to the new temporary site's database

4. run zc_install on that new temporary site

5. now export just the tables related to customer details: customers, customers_info, address_book.
   Now, if you also have group-discount-prices set up, you'll want the group_pricing table as well.
   Reference: http://www.zen-cart.com/wiki/index.php/Developers_-_Database_Schema#Customer_Information

6. Now you've got the customer data available in a format suitable for the specific ZC version you upgraded to in step 4 above. So, if that format was 1.5.1 and later you decide you want to upgrade to 1.6.0, you'll need to set up a 1.5.1 site and import that data, and then upgrade that 1.5.1 site to 1.6.0 in order to upgrade that data. Basically repeating steps 1-5 all over again, but with a new set of versions.

Not recommended for someone not familiar with databases and tools like phpMyAdmin.

Hi DrByte -

appreciate the guidance.

So, importing the old 1.3.9h database into the temporary 1.5.1 new site's database.

Would I drop the tables in the temporary 1.5.1 new site's database prior to importing the old 1.3.9h database into it?

Step 4: This would be the second time I'm running zc_install on the temporary 1.5.1 site. The first time running zc_install would be in Step 1 am I correct? And if so - zc_install in Step 4 would determine that the data contained with the database is actually 1.3.9h data (thus giving me the database upgrade option), even though the database itself was created by a 1.5.1 zc_install?

You also mentioned, this is for customer info only - would it work for order history - obviously provided I export all the required order tables as well?

yaseent:

Hi DrByte -

appreciate the guidance.

So, importing the old 1.3.9h database into the temporary 1.5.1 new site's database.

Would I drop the tables in the temporary 1.5.1 new site's database prior to importing the old 1.3.9h database into it?

Step 4: This would be the second time I'm running zc_install on the temporary 1.5.1 site. The first time running zc_install would be in Step 1 am I correct? And if so - zc_install in Step 4 would determine that the data contained with the database is actually 1.3.9h data (thus giving me the database upgrade option), even though the database itself was created by a 1.5.1 zc_install?

You also mentioned, this is for customer info only - would it work for order history - obviously provided I export all the required order tables as well?

So step one creates a database and the configure.php files to boot. (That's part of why the prefix is needed if used, beccause the process of upgrading and then transferring the tables will keep them all named the same. The database created in this step essentially is disposable once the process is complete.)

It wasn't explicitly stated, which is why the final comment about familiarity with tools such as myphpadmin, butyes wouldneed to drop the tables that are to be replaced prior to importing the same tables. (In the case of step 3, all tables would be dropped. In the case of completing step 6/using that upgraded data, the tables identified toimport would need to be dropped.

The question about running zc_install twice, yes that is true, though the database tables created would be removed when they are dropped to support the import. Effectively between those two steps a shell exists in which tables can be created. In a sense it wouldn't matter if that database was created by 1.5.1 or any other process so long as any particular settings for the database shell were the same/compatible with 1.5.1.

The upgrade process described above by Dr. Byte would work for the order history tables as well, though would need to identify/have identified all the desired/necessary tables, which at the moment I can not answer which are applicable.

mc12345678:

So step one creates a database and the configure.php files to boot. (That's part of why the prefix is needed if used, beccause the process of upgrading and then transferring the tables will keep them all named the same. The database created in this step essentially is disposable once the process is complete.)

It wasn't explicitly stated, which is why the final comment about familiarity with tools such as myphpadmin, butyes wouldneed to drop the tables that are to be replaced prior to importing the same tables. (In the case of step 3, all tables would be dropped. In the case of completing step 6/using that upgraded data, the tables identified toimport would need to be dropped.

The question about running zc_install twice, yes that is true, though the database tables created would be removed when they are dropped to support the import. Effectively between those two steps a shell exists in which tables can be created. In a sense it wouldn't matter if that database was created by 1.5.1 or any other process so long as any particular settings for the database shell were the same/compatible with 1.5.1.

The upgrade process described above by Dr. Byte would work for the order history tables as well, though would need to identify/have identified all the desired/necessary tables, which at the moment I can not answer which are applicable.

Hi mc12345678 -

thanks for the clarification.

So - essentially your method and DrByte's methods are pretty much similar - with the exception that DrByte's method uses a 1.5.1 database "shell" prior to upgrading the database itself...

yaseent:

Hi mc12345678 -

thanks for the clarification.

So - essentially your method and DrByte's methods are pretty much similar - with the exception that DrByte's method uses a 1.5.1 database "shell" prior to upgrading the database itself...

Perhaps a little incorrect emphasis was placed on the database creation. I would definitely use the ZC install process to create the shell unless there was some alternative reason to duplicate the process outside of ZC. But it's sort of like recreating the wheel, why go through the effort unless for proving that it is possible. Working with existing tools is far quicker and easier than starting from scratch and for those that are running their business time and effort should be put towards that end more than meddling around.

The point was to provide some perspective on the comment:

actually 1.3.9h data (thus giving me the database upgrade option), even though the database itself was created by a 1.5.1 zc_install?

The upgrade option does not go into the database and say, I see that you were created by 1.5.1... It looks at factors like version information in one of the tables and some other things that I haven't dug into to possibly provide a description. Again why I would use the applicable install/upgrade option(s) to save a lot of that how to make it happen time and effort.

@yaseent - don't get confused at this stage... :wink2: Dr.Byte's explanation is basically the same as mine, except for the fact that he took the "for dummies" approach and explained each step in detail, as opposed to me because I assumed you knew the basics already. However, his explanation is MUCH better than mine because this post will very likely help many other users who might actually be total beginners and might skip or miss something trivial that I forgot to mention (like, for example, database prefix).

Hi balihr,

definitely, and thanks for all the help - will use this entire thread as guidance while I'm doing the copy-over.