1

I've to move a lot of products from an old Magento site (v. 1.4) to a new one (1.7) with fresh new theme with new modules it's also a multisite, infact there' already a lot of stuff I configured in order to make it work right. so if I change the database it probably will stop working.

So, before start moving... what do you guys suggest me is better. Move only the Products + images or move the entire database? I read a lot of docs. And saw it's a long work upgrading Magento from such an old version to a newer one. Plus at the end the stuff I guess, I need from the old site are only the products and maybe some info like name, phone etc. (but that could be added by hand)

what you think I should do?!

Improve this question

3 Answers 3

Reset to default
4

1.4 to 1.7 is pretty painless - if you're only interested in the database contents. Truncate the log tables, set the theme to base/default - then start the upgrade.

When we do it, the first step is to upgrade to 1.4.2.0 - then jump to 1.7.x.x.

I'd certainly rather do that than do a product export/import.

Improve this answer
3
  • thank you for the reply! That's a good news :) but I'm currently working on local so I have to download the whole database from live website and do everything on local. On local I have already installed 1.7 and configured it to work with multisites and did a theme, the only thing missing are the products. It's still better doing it this way instead export/import? Am I going to loose all the configuration I've done to the local setup once the other db is imported?! thank you again
    – Sean Johnson
    Commented May 21, 2013 at 12:59
  • 1
    Hi Sean, As sonassi said, give up on the "export/import" idea. I would start from scratch and run the upgrade. It will be by far the cleanest solution.
    – Fran
    Commented May 21, 2013 at 14:02
  • People who go the import/export route go through such exquisite pain. At the end of the day they find there's more to Magento data than what the exports export. For example, how many custom attributes have you set up? Did you get them all created if you realize they should exist on the new installation? And then they decide that they did really want all that order history. That doesn't come over...
    – Fiasco Labs
    Commented May 21, 2013 at 14:36
2

I'm no expert, especially in multi-store setups, but I can share my experience since I just recently did both, in planning for a server move/upgrade.

First time around I did a export from 1.4.1.1 and imported products using Magmi into a fresh 1.7.0.2 install. I found this worked fine, but eventually I realised that I hadn't captured everything across to the new site. Everything else other than Products were lost, and required another method to import (if even possible). This included Historical Sales Orders, Customer accounts, Newsletter subscriptions etc. The more I dug into it the more I realised this was a losing battle and wasn't worth the effort.

Secondly I tried the SQL export and upgrade from 1.4.1 -> 1.4.2 -> 1.7. I ran into a few hiccups with Foreign Keys during the upgrade (PROTIP: set FOREIGN_KEY_CHECKS = 0 before running the installation), but once these were sorted out I had everything captured. Orders, Products, Customers etc.

My money is that you will run into less headaches going with a DB upgrade

Improve this answer
4
  • 1
    Why would you set "FOREIGN_KEY_CHECKS" to be 0 ? I think it could potentially cause more problems. There will probably be hiccups during an upgrade, but altering the database looks a bit like a hack.
    – Fran
    Commented May 21, 2013 at 14:00
  • I forget exact details now, but it was related to the order it was attempting to update the tables. There was also a issue with a extension table, that again could be fixed this way instead of dropping/adding the foreign keys manually. Much more likely to get that wrong due to human error.
    – Jonathan Devere-Ellery
    Commented May 21, 2013 at 14:20
  • 1
    Probably because the data was being imported into a database where tables already existed. In my experience, the FKC errors go away if you're importing into an empty database.
    – Fiasco Labs
    Commented May 21, 2013 at 15:40
  • Set FOREIGN_KEY_CHECKS=0 once and do it forever. Because once you've broken the key relationship - it will break everything thereafter and you'll find your only solution is to hack your way through SQL queries to get them to execute without error. Set it with extreme caution and only if you know what you are doing.
    – Ben Lessani
    Commented May 21, 2013 at 16:22
1

There is no need to step to 1.4.2 before going to 1.7

This is the way we do our upgrades (Everyday)

Take a fresh dump of your database. Clean all your log tables.

Use the following as minimum - You can truncate more if you wish. There maybe some tables that exist, if you get an error on your truncation just comment out the table.

SET foreign_key_checks = 0;
truncate dataflow_batch_export;
truncate dataflow_batch_import;
truncate log_customer;
truncate log_quote;
truncate log_summary;
truncate log_summary_type;
truncate log_url;
truncate log_url_info;
truncate log_visitor;
truncate log_visitor_info;
truncate log_visitor_online; 
;truncate adminnotification_inbox;
;reports
;truncate report_viewed_product_index;
;truncate report_compared_product_index;
truncate report_event;

;send a friend
truncate sendfriend_log;
;core logs
truncate core_cache;
;truncate core_url_rewrite;
SET foreign_key_checks = 1;

I would not truncate core rewrite if you have a bunch of custom re-writes created!

Get a fresh version of Magento 1.7 Point local.xml to original database Run upgrade!

I do agree about setting foriegn keys to 0 (And leaving them there until the upgrade completes. However I would first try it with it set to 1, if you error out then set to 0.

Remember you need a new database with each attempt, you can not import into the same database, your new tables will exist and you will get an error!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.