Please note that this is not a full review of the Cart2Cart service. We only had experience with migrating from a customized Zen Cart site to Magento 1.4.1.1. We make no attempt to critisise or praise Cart2Cart. This article simply offers a view into the benefits and pitfalls of the result in our specific case.
In one of my recent Magento projects, our client used the Cart2Cart service to import product, customer and order history data from a Zen Cart site into their new Magento site. The promise seemed great, the cost very competitive and the convenience of having all the customers order history was also compelling.
It is of note that the source Zen Cart site had some custom work done on it and the Cart2Cart service created a specific migration suite and performed the migration work manually in our case. In other words, we did not use any Cart2Cart online wizards.
So let’s break our experience up into the 3 areas:
1. Customer Import
This is the most straightforward import since Zen Cart uses the same password encryption mechanism and also stores comparable customer data as Magento. We found no issues with this part.
2. Order History
To our surprise, Cart2Cart successfully imported all previous orders into Magento. The order history gave us no problems either. Our client raised the question of the dashboard totals not being close to the actual sales figures but it transpired that most orders were imported in Pending state. I don’t really know what the orders original Zen Cart order statuses were and whether they could have been imported as Complete had their Zen Cart status been set accordingly.
In any case, Cart2Cart is the only service known to us that provides order history import into Magento, so big thumbs up on this.
3. Product Import
This area gave us the most headaches.
The original catalog contained mostly configurable products based on size attributes. We already had a size attribute set up in our default attribute set however, the cart2cart import ignored this and created new size attributes for almost every individual configurable product. To make things worse, for each of the new size attributes, the import also created a separate attribute set.
This means that the import ended up creating over 100 separate size attributes as well as the same number of attribute sets.
Ok, so the store can work fine with all this extra data but it looks and feels messy especially since the attribute names have long unique identifiers as you can see from the screenshots.
Cart2Cart created size Attributes
Cart2Cart created Attribute sets
Another thing I noticed was that the category maintenance now had an additional tab called “General” with only a Short_description field. Presumably Zen Cart has an additional category attribute that was created and imported but at least I think it would be nice if it could have been added to the standard Magento General Information tab.
A good thing with the product import was that it managed to import the multiple product gallery images the original catalog had and most of the other product data was complete.
So far so good.
After we had the store live for a while, we began receiving reports that the products don’t automatically go “Out of Stock” after a purchase of the last product making up a configurable product. This issue was easily remedied by manually running the stock index refresh but this should not happen in a healthy Magento store since Magento implements an event observer on sales_model_service_quote_submit_success (when a sales quote object is successfully submitted upon receipt of a new order) that runs the reindexQuoteInventory() method that updates the stock status for the items in the order.
So we embarked on a hunt to find the problem. After many debugging hours, we finally worked out that the data in the Magento product database for configurable products was incomplete. It transpired that simple products are linked to their configurable product parents in two separate database tables:
- catalog_product_super_link
- catalog_product_relation
The first one was set up correctly, however the second one did not contain the same parent-child links and this was the reason that the Magento stock indexer couldn’t update the stock status correctly for our imported products.
Once we ran a SQL query to update the missing data, everything was fine.
Re-saving an imported configurable product also remedied the situation for that particular product.
Conclusion
Cart2Cart provide a great service to store owners who need and want to migrate their existing shop data across to a Magento store. However, given Magento’s complexity this is not always a straightforward process.
I found the customer and order history import very effective and they also provided an incremental import script that allowed for the import of any additional orders and customers on the go-live date. This was very valuable as it made us independent from having the Cart2Cart team available on go-live.
The product import wasn’t so perfect as outlined. Had we only had simple products to import, everything would have been fine but in our case, the catalog is messy and there were issues we had to spend a lot of time resolving.
My opinion is:
Use Cart2Cart if you want to migrate customer and order history data but be careful if you have a complex product setup. If your source store contains only simple products, then it would be fine. If you have complex products, then I would check if the import could be run only to import simple products and manually create the desired complex products in Magento or accept that your catalog will be messy.
Pros:
- Very reasonable cost of service (depends on the number of items imported)
- No hassle import of Customers
- Only service that imports Order History (to our knowledge)
- Product import covers multiple (product gallery) images
- Incremental import script we could run ourselves
Cons:
- Configurable product import adds multiple attributes and attribute sets for the same attribute
- Configurable product data integrity after import is incomplete in Magento (Cart2Cart could address this)
- Additional category tab created
What is your experience with services that offer data migration to Magento?
Update
We just read on the Cart2Cart blog that they have taken the points in this review seriously and worked on improving their service. We appreciate this course of action and definitely would recommend giving Cart2Cart a go.
Originally published on magebase.com. Copyright © 2010 Magebase - All Rights Reserved.
Proud members of the 
We used Cart2Cart back in March and ran into problems with meta tags. None of our product meta tags (title, description or keyword) made it over, which was a major headache. I ended up having to do a manual import over from ZenCart (and figuring out how to tie the differing product ids together was another story in itself).
But yes, it sure was nice having most of the info moved over for us!
I’ve done two Cart2Cart migrations. One good, one bad. The first was X-cart to Magento 1.3. This was when Cart2Cart just came out. Everything went smoothly. My first import try was missing something like custom options. I emailed them, and the head guy at the time fixed their process AND re-did the import for me.
The 2nd migration was a nightmare. It was Magento 1.3 to 1.4. You’d think, this should be a cinch! Well, not only did I get the errors Robert mentions in his post (an additional tab called “General” with only a Short_description field, the new size attributes, incomplete data/identifiers), but I also got indexing errors that prevented some saving. After about 20 hours of trying to fix the data issues, including following advice from the forums and Cart2Cart that did not work, including them blaming it on a Magento bug, I gave up and did the migration manually. Fortunately, Cart2Cart refunded my money.
So, 2 totally different experiences: 1 great with great support, and 1 terrible with “not our fault” support.
I’ll second Robert’s advice. This might work for you, and it might not. I suggest trying it, but not counting on it. If you use their wizard, be sure to mark the option that says something about “clear target db first?”. Cart2Cart said that was part of the problem – even if you’re starting with a fresh install.
@DB & @Joe
Thanks for adding your feedback to this. It’s good to hear other people’s experiences.
Curious – I’m looking to do the same import as you. Did customer passwords come across successfully, or did everyone need to reset their password post import? Did this go over well?
I have to say I had an excellent experinece with Cart2Cart. My migration good not have gone more smoothly. No hitches or hic-ups.
I was migrating from ZenCart to Magento.
Support was the best…totaly top notch.
I have only done the one migration so can not speak to the consistency, but do believe the folks at Cart2Cart will do all they can to make the process as painless as possible.
CF Hughes
Thank you for posting your positive experience. I think the service Cart2Cart provide is something that is necessary and very useful so it is great to hear that there are satisfied customers.
I had a much different experience with cart2cart with my Zen cart import. I would not recommend their service as it cost me more to pay someone to clean up the mess it made than it cost to do the import. The cart2cart grew my database from 324 tables to over 680 and they would not fix it. Their answer was “we have done it before without problems”. They just left my store in an messed up state and would not redo the import.
Dear James,
Thank you for a comment. Your opinion is very valuable for us. At this point we have already made more than 900 successful Zen Cart migrations. But very frequently some issues may encounter during the migration, which mostly are connected with a specifics of the store, or other aspects. In this case we ask our clients to provide us with some additional information and permissions to fix this. But it’s up to our client to give or not to give us this information.
In your case, the migration itself went ok. In fact, there was an issue which was connected with the specifics of your store. After each migration we do dump file which shows all success and errors of migration process. So we asked you to restore dump file to fix all problems or give us access to your FTP (so we could do it by ourselves). You didn’t give us the opportunity to fix the problem and asked for refund. We would be glad to help you.
Hi there,
We’re looking to transfer member data only from epages to Magento. Both customers and subscribers. Sorry to post this here, but it seems the only article tagged ‘data migration’. I understand the passwords in epages are encrypted, so we can’t transfer them with the user data.
We presently have everyone’s password in Magento set to a single default that we will tell them to change on their first visit to the new Magento site (perhaps with a store discount voucher to encourage this). But we’re having doubts about this for security reasons. It’s a hosted DPS page taking payment, so no credit card info would be available to anyone who ‘hacked’ another user’s account by guessing usernames.
So I’m really interested hearing anyone’s methods employed when migrating users from a different platform (especially, but not limited to, epages) and getting the subscribers/customers to do the necessary thing on the new Magento site (visit, log in, check details, update password if necessary). One possible solution – is there a way to generate a new password on the fly via a unique link in a bulk email?
Regards,
JP
JP, I’ll try to answer your question.
Unfortunately, Cart2Cart service does not migrate clients credit cart information and passwords. Migration process goes on a separate Amazon EC2 server and all data will be cleared after finishing process. Also all connections goes through secure HTTPS protocol and only authorized staff have access to the migration process.
Customer accounts will be migrated from source cart to target. Cart2Cart doesn’t have an option to migrate the passwords, because they are encrypted in most shopping carts by some specific way. Your clients should use Password Recovery tool on your target shopping cart to access their accounts. Although, orders history will be available for them.
Best regards,
Mariana Onysko
Hi
has anyone experienced a Prestashop => Magento migration ? Any feedback?
And Concerning the customers passwords migration, i came up with a solution , but it is from Prestashop to Magento , i will explain:
Magento password encryption is : MD5 + SALT , which means they add a random word to each password , and then encrypt it using MD5.
Example :
Your password : mypass
Random word : whatever
SALT : whatevermypass
CONVERT MD5 : FKEOR54SfRrRrg59 (example)
Password stored: FKEOR54SfRrRrg59:whatever
concerning Prestashop it is the same algorithm md5 + salt , the unique difference is that they use the same salt word for all password and that word is placed in a the config file (Cookie_Key).
So after the Prestashop => Magento migration ,i’ve just added that salt word to the stored hashed passwords using a sql query
Update YourTable set Password = concat(Password , ‘:SALTWORD’)
I hope this can help you.
What was your solution to the attributes issue and would you mind posting or describing in more detail the SQL call you used to fix the catalog_product_relation table issue?
@Charlie The SQL is simple, if there are no entries in catalog_product_relation:
If there already are some values in catalog_product_relation, then you’ll need to work out how to just insert the missing value pairs. You may be able to truncate the catalog_product_relation table and then run the above insert. I advise backing up your database before tinkering, of course.
Why do they have to store the links in two tables????????????!
I have the same problem , Everything seems good eventhought i have no row on catalog_product_relation, i was wondering how the products are linked i just knew about the second table existence.
Can this affect my website or bring problems? the unique thing strange which seemed was : the configurable product quantity , it was a random number , but that doesnt make any problem because its the simple products quantities that matters.
Can you explain to me what problem can this make? i did run the query i still have the configurable product quantity random, but once i click on Save product in the back office it gets 0 which is the good value.
Thank you.
I asked Cart2Cart service they told me that catalog_product_relation isnt for Configurable/Simple products associations , it is used for another purpose!!!!!
I did the cart2cart migration a few months ago and the catalog_product_relation table seemed to be just fine however due to the immense number of automatically generated attributes and attribute sets I have had to spend the past week manually renaming and reassigning attributes and sets.
While I didn’t want to complain at first, now I am confident that fixing cart2cart’s migration quirks has cost me more time than if I had manually moved every product myself. They claim to have updated the service since I used it however given the convoluted steps necessary to repair all this I’m skeptical that they’d get it right.
Their customer service is to be expected. They are 8 or 9 hours ahead there so there’s usually at least a half-day delay in communicating, and from what I can tell they have a non-technical english representative that didn’t develop the service so they can’t really answer technical questions.
My advice, if you come across this post and you’re looking for a way to migrate shopping carts (I did OSCommerce to Magento), is to just do the database work yourself. It’s a daunting task but the risk is you spend money on cart2cart and end up having to do more dB work.
yes concerning products its a pain in the ass!!!
Price problems , attributes , images affected only to configurable products , stock problems… but to be frank , concerning the customers and order and images… its all fine , specially that orders are the hardest feature,
so from your answer is it ok if i have the catalog_product_relation table empty?
@Wadii, @Charlie
I understand your frustrations. But, Magento is a complex piece of software and it is easy to miss an essential piece when developing third party services such as cart migrations.
To get back to the catalog_product_relation table, I think it is important to have it contain the expected data since this seems to be how it works in the normal Magento operations with configurable products. It may be that it is not necessary for the catalog browsing and purchasing, however is appears that it IS used by the catalog stock inventory indexing process so, it’s pretty essential, especially if you are updating the inventory via import files.
By “the expected data” you mean the same lines as catalog_prodct_super_link right?
thank you Robert
And concerning the problem you faced about product doesnt display out of stock after last item purchase , i guess it is due to the configurable product quantity which was a value > 0, we had the same conflict and we fixed it just by the data reindexaction… to be frank i did a lot of manual migrations for discounts , related products , url mapping , pictures positions (Anyone want these solutions can contact me) , and the store now is doin’ great , but i’m still confused about two things :
- catalog_product_relation : do i have to fill it or not.
- The configurable product for most of products which is a value > 0 ,and i do have to save the product so as it takes 0 value , but despite of that it doesnt occur any problem!!!
Thank you guys for the help
@Wadii
My best guess from this experience is that the data in catalog_product_relation must correspond to the data in catalog_product_super_link to have the stock levels updated correctly when someone purchases a product.
Clearly, Magento updates the values in both tables when a product is saved via the back end, however, other action may just look at one or the other table. Without digging into the sql bowels of Magento and seeing where it is using these tables, it’s had to tell which part is using which table.
My other guess is that the configurable product quantity shouldn’t worry you too much if everything else is working correctly and the above mentioned tables have the correct and corresponding data.
@Robert,
Thank you very much!
Hi Robert! what was your solution concerning the thousand attributes? is your store working with that? or did you rename all of them???
My solution was a set of custom scripts I wrote that deleted unused attributes and attribute sets, then manually renamed them one-at-a-time. There were something like 200 items that I ended up manually renaming, it couldn’t have taken more than 30-45 minutes though designing and testing the scripts took 4-5 full work days. I don’t want to post all the code because it took me a lot of work and misuse means a forever ruined dB.
However here is a script that lists all the attribute sets, their custom attributes, the products that use that set and the attribute options for those products (note: script of course needs mysql connect with your db login at top):
$sql = "SELECT * FROM `eav_attribute_set` WHERE `entity_type_id`=4 AND `attribute_set_id`>$att_set_id AND `attribute_set_id`!=4 ORDER BY `attribute_set_id` ASC"; // Get all attribute sets $e_att_set_res = mysql_query($sql); //echo $sql; while($e_att_set = mysql_fetch_array($e_att_set_res)) { $att_set_id = $e_att_set['attribute_set_id']; $att_set_name = $e_att_set['attribute_set_name']; $att_ids = array(); $sql = "SELECT * FROM `catalog_product_entity` WHERE `attribute_set_id`='$att_set_id'"; $cat_prod_ent_res = mysql_query($sql); //echo $sql; if($att_set_id != 4) // If not the default set { if(mysql_num_rows($cat_prod_ent_res) > 1) { echo "<br />$att_set_id $att_set_name <br />"; $num_prod_att_sets++; $show_atts = true; // for each product in the attribute set while($cat_prod_ent = mysql_fetch_array($cat_prod_ent_res)) { $ent_id = $cat_prod_ent['entity_id']; $type_id = $cat_prod_ent['type_id']; if($type_id == "configurable") { // Get all attributes for this product $att_ids = array(); $att_types = array(); $sql = "SELECT * FROM `catalog_product_super_attribute` WHERE `product_id`='$ent_id'"; $cpsa_res = mysql_query($sql); while($cpsa_arr = mysql_fetch_array($cpsa_res)) { $att_id = $cpsa_arr['attribute_id']; $att_ids[] = $att_id; $sql = "SELECT * FROM `eav_attribute` WHERE `attribute_id`='$att_id'"; $cpea_res = mysql_query($sql); $cpea_arr = mysql_fetch_array($cpea_res); $att_code = $cpea_arr['attribute_code']; $att_types[] = $cpea_arr['backend_type']; echo "att: $att_id $att_code <br />"; $show_atts = false; } } elseif($type_id=="simple") { $sql = "SELECT `value` FROM `catalog_product_entity_varchar` WHERE `entity_id`='$ent_id' AND `attribute_id`='60' LIMIT 1"; $cpev_res = mysql_query($sql); $cpev_arr = mysql_fetch_array($cpev_res); $prod_name = $cpev_arr['value']; echo "$ent_id $prod_name "; $i = 0; foreach($att_ids as $att_id) { $att_type = $att_types[$i++]; if($att_type == "varchar") $valtable = "catalog_product_entity_varchar"; else if($att_type == "int") $valtable = "catalog_product_entity_int"; $sql = "SELECT * FROM `$valtable` WHERE `attribute_id`='$att_id' AND `entity_id`='$ent_id'"; $cpe_res = mysql_query($sql); $cpe_arr = mysql_fetch_array($cpe_res); $att_val = $cpe_arr['value']; $sql = "SELECT * FROM `eav_attribute_option_value` WHERE `option_id`='$att_val'"; $eaov_res = mysql_query($sql); $eaov_arr = mysql_fetch_array($eaov_res); $option_val = $eaov_arr['value']; echo " $option_val"; } echo "<br />"; } } /* ?> <form method="post"> Rename set: <input size="75" type="text" value="<?php echo $att_set_name; ?>" name="att_set_name" /><br /> <input type="submit" value="click to rename" name="rename" /> <input type="submit" value="skip" name="skip" /><br /> <input type="hidden" value="<?php echo $att_set_id; ?>" name="att_set_id" /> </form> <?php break; */ } else $num_bad_att_sets++; } }Thank you very much , gonna use that tomorrow… i was trying to rename the attributes generated by Cart2Cart but i’ve noticed once i rename an attribute from the bakc office , a problem occurs and then when i consult the product page i see no dropdown lists… some products did show up OUT OF STOCK its like it doesnt recognize its simple products anymore , have any idea about that? is it impossible to rename Cart2Cart generated attributes?
@Wadii, well, our client had decided that they could live with the created attibute sets and attributes and would clean them up over time so we didn’t actually do anything about this. Sounds like Charlie has some very useful insights and can help more than I can.
Thanks Charlie for sharing your experience and code.
Wadii,
The fields I changed in the back end (using phpMyAdmin at first to test) were the “attribute_code” in the “eav_attribute” table and the “attribute_set_name” in the “eav_attribute_set” table. For me, changing only those fields produced the desired results. (This might be relevant for you at some point too, Robert, since Magento doesn’t offer a way to change the attribute codes from the cart2cart generated ones).
Only change the attribute code and set name, don’t touch the other fields especially the “id” fields, and remember the attribute code has to be unique with only letters numbers and underscore no spaces! Hopefully I’m not missing something and this has the same effect on your system. I’m on 1.4.2 btw.
The above script I posted should help you get a handle on what attributes and sets go where, assuming it functions the same on your system.
Thank you , but the problem that i have got is with the frontend label , the attribute label showing up on the front end…. i really cannot change it , thank you once again Charlie
I suggest you to manage attribute sets in Magento via Store Manager for Magento from MagneticOne (http://www.mag-manager.com/) and make your business tasks automatic and fast in resolve.
Yes yes , but technically speaking this shud happen , as i’ve updated the frontend_label column value in eav_attribute , went to a specific product checked the default attribute label , but it stills display the very first value… it is really strange!!!
I was able to change the “attribute_code” in the “eav_attribute” table and the “attribute_set_name” in the “eav_attribute_set” but the not the frontend_label!
thank you for the suggestion Mariana
Allright i was able to do it , by changing an instruction on configurable.phtml $attribute->getLabel() to $_attribute->getProductAttribute()->getStoreLabel()
So i checked that when editing an attribute (frontend label , code , attributeset name) from the database everything works perfect , but once i go on the attribute page on the back office , i do nothing but just clicking on SAVE and the product is messed up , on the front end i dont see the drop down lists of the product even the relation between the product and its simple produts is gone… any idea?
Ok if anyone has faced the problem it is due to this:
When i click Save attribute , the backend_type column in eav_attribute table changes from varchar to int.
The solution was a sql event that runs on schedule in order to update the value to VARCHAR again.
I used Cart2Cart to migrate from standard Zen-Cart to Magento (1.4.1.0), with about 100 simple products, and all wen very well. I was very pleased with the process and outcome.
Regards,
Eddie
I think I will transfer from ubercart to Magento using cart2cart service very soon.
I will post my experience when it’s all done.
I do have vast of complex products, which made me a little hesitate.
Good news!
We have fixed this stuff:
- Configurable product import adds multiple attributes and attribute sets for the same attribute
- Additional category tab created
We constantly work to make Cart2Cart better for your business needs.
We just did a migration from Ubercart (module for the Drupal CMS) to Magento and are fairly pleased with the results. We did products only and didn’t touch customers or order history. It’s not hard to see how difficult it can be for someone like Cart2Cart to be able to handle all of these different scenarios from multiple systems.
A write up of our experiences here: http://www.websitemaintenancelabs.com/dev-blog/migrating-drupal-and-ubercart-magento
I made the mistake of using this service and all it resulted in was a complete mess. It’ll take you longer to clean it up afterwards than to hire a freelance guy to do it from the start. The script is’nt working properly and the support staff doesnt seem to understand what you’re saying. Maybe you could be one of the lucky ones that get a successful migration but chances are that you’re left with a messed up database and just have wasted a lot a time.
Hi Edvin,
We are extremely sorry for what you had to go through. We would greatly appreciate if you could leave us your feedback and we’d make sure to work on the things you’d like us to improve. If there’s anything you’d like to add, please complete the dedicated complaint form here: http://www.shopping-cart-migration.com/component/artforms/?formid=7.
At times, there happens to be an issue that is hard to resolve on the spot, that is why we are always open for your comments and suggestions. Please let me know if there’s anything we can do to make it work for you in the future. Cart2Cart is constantly striving for improvement. We appologize for any kind of inconvenience that might have been caused by it.
Thank you!
My experience is fairly inline with others.
In 2010 we did a manual Cart2Cart migration from XCart to Magento 1.3 multi-store installation. Orders good, customers good, products passable. It could be that my expectations for a migration between two different stores was pretty low but we worked with it.
We’ve just had Cart2Cart perform an assisted migration, (hoping to make the shortcomings of the first go away) from Magento 1.4 to Magento 1.6. You’d think a migration between the same system would be easy, but… Orders good, customers good but the products, categories and attributes, are a complete mess. They say on their site that they can handle these things but THEY CAN’T. Don’t expect them to do it right! You will be dissapointed.
Here’s part of their reply:
…”This is connected with the fact there are four attribute sets at your Magento Target store and our service does not allow to work with this kind of issue.”…
I’m going to dig through the mess and find out if it was worth it or not. It might be time to write my own migration script, (do it for every other site I manage).
I’ll try to keep ya’ll updated.
Have Fun – Bill
Hi all,
Bill has completed his migration to the brand new Magento installation. During the demo migration a limited number of products, customers and orders has been moved to the new cart free of charge. Demo migrations are always performed as trials before the actual full migrations to let each client see how the end results would look like. As a result, all the customers and orders have been migrated correctly, while some product information has been disrupted. We’ve informed Bill that some of the product information could not be migrated correctly and offered our services to customize the migration that could possibly correct some of the issues. Bill decided to go ahead with the migration on his own, though we’ve warned about the possible issues. Consequently, when the full migration was completed, product information was migrated incorrectly.
We’ve offered Bill to customize his migration and fix some of the issues with his product info and restart the migration for him.
Unfortunately, Bill was not open for further communication. Therefore, we could not provide the best service for the issues arisen.
In any case, we are always willing to go an extra mile for Bill and all our clients. So, please feel free to contact us at any time and request assistance with the results of your migration. We will make sure to do everything on our part to make your store run smoothly on your brand new shopping cart.
With regards,
Cart2Cart Team