Merging Magento Installations

Heads up! This article was written over [[elapsed]]. While it may still be helpful, please verify any information, as my perspectives and practices may have evolved.

So we took on a project to redesign a current Magento store. We developed the new site, in isolation from the previous store, on a fresh Magento installation. When it came to launching we needed to merge the customer and order data from the old site into the new site, while keeping the new site’s CMS pages, Static Blocks and general configuration settings.

To save some poor hapless Magento Developer’s soul I’ve decided to document our findings.

Observation 1: Merge the new database into the old, not the other way around

Think about it. The tables that we need to keep from the new installation are well known: core_config_data and the cms_* tables. Order and customer tables are far less obvious. There are relationships that you’ve never even considered that exist between the most obscure tables. It’s for this reason we decided to import the old database first onto our live server, then copy over the new tables we required when we’re ready.

We’ve now got a, relatively, old schema along with a, relatively, new codebase. This means that there could be a Magento version mismatch between these two components. Not to worry, this leads us nicely onto the second observation.

Observation 2: Let Magento do the heavy lifting upgrading your schema

If you take the time to checkout the core_resource table in the database you’ll notice that Magento does a fairly good job of versioning the schema at an individual module level. Theoretically, when you load up that page for the first time on the live server, Magento will detect the version mismatch and work its way through the copious mysql-*.php files dotted around the module folders, incrementally altering tables, adding default data, creating tables, until we’re current.

We found that this did in fact happen, although not entirely as smoothly as we would have hoped. That said we didn’t need to make any manual changes to the code, just needed some patience with the refresh button. We got a couple of error messages, but..

Observation 3: A Magento error is not the end of the world

Really, in this case it isn’t. We got 50-60 ALTER TABLE commands fail on us for one reason or another. Magento appears to handle these find. Just refresh the page and it’ll move onto the next statement, versioning the schema as it goes. We did get one refresh that took around 10 minutes to complete, so make sure you’ve got that timeout value in your php.ini jacked up.

You may get some problems with redirecting to /errors, or whatever, but just enable developer mode and that should go away.

Observation 4: Add your tables at the very end

Don’t go and add in your new tables until the entire process has completed, otherwise it could get very confused. Theoretically it should be fine, but we were getting some funky errors when put them anywhere but last.

Abide by these tenant and you should save yourself some headaches. Remember to try this out in a no pressure environment, i.e. not 1am in the morning on the live server, first. If you’ve got any questions, or further wisdom, then please do let me know.