I have read through numerous posts and articles on upgrading from version 1.x to 1.x+1 and there are several things that i need to confirm my thinking is correct.

1) code in the community pool should be third party extensions and as such it should be possible to upgrade these, so the way to do this is to archive them and transfer to the new version then perform any indicated upgrades.

2) code in the local pool is probably locally developed and will need to be transfered to the new version and then tested and modified

3) in skin and app/design the custom elements for both local and community pools will need to be tracked down. This includes the media folder and various miscellaneous items such as app/etc/modules/*.xml files. Other than checking on a directory by directory basis there seems no easy way to do this

4)Several times i have seen one of the steps in the upgrade being to flip certain switches in the database via admin. e.g. logging to be on, but then a later step is to replace the "new" database with the one from the original version. So presumably this switch flipping is done in the database/version you are upgrading from.

5) in all cases it seems to be a fraught and error prone process that will require varying amounts of manual intervention and troubleshooting

  • What version are you upgrading from and to? 1.3 -> 1.9 is completely different than 1.8->1.9 You can't apply the same approach to each. Oct 17, 2014 at 13:44

1 Answer 1


To be honest the upgrade procedure you outline above is not in my opinion actually the most practical, or indeed in many cases feasible way of doing it. Migrating all existing changes to a completely new install just isn't realistic for many installs and with widespread changes across an install finding them all and migrating them - unless you are extremely familiar with the fileset, is inevitably going to end up in leaving changes behind probably introducing bugs in the process. It could also take a very long time. I'm of the opinion that you are actually going to have less bugs to fix by just upgrading the existing install than by migrating everything across to a brand new install.

A couple of important points though:

  1. You really should use a repository to manage your fileset.
  2. Never upgrade a production site directly, always upgrade your local development environment clone first and bug fix there. Code should only ever go out to production once you are happy things are working well both locally and also in a live staging/dev environment the store owner can test on.

Essentially I would recommend you look at the following:

  1. Review all third party extension versions and install upgraded versions documented as being compatible with the Magento version you are upgrading to.
  2. Review all local modules to ensure they are compatible with the new Magento version and modify as necessary. This includes things like looking at any method rewrites and comparing the current Magento core version method with the new to ensure the rewrites are still correct.
  3. Remove all core file rewrites under app/code/local/ and instead create a local module to handle whatever changes these introduce.

It's also a good idea to review template and layout changes but often you can actually leave this until after the upgrade while you are testing as these changes are less critical and generally much more moveable between versions. Once you have performed the upgrade locally it's a case of basically just using the store as extensively as possible to uncover any bugs which may have been introduced. Once you are confident things are working well locally, deploy the upgrade to the the dev/staging environment so that more people can test the changes, once this looks clear finally deploy to production.

As a general rule, the more heavily customised the store the longer upgrading it will take, if you have a store which is only lightly customised it's likely upgrading will be relatively fast with much fewer checks needed beforehand, and much fewer bug fixes required afterwards.

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.