How do you give estimates for Magento upgrade?

Question

Overview:

This question was originally asked and later closed on StackOverflow. We stated in meta, that here is the right place for this question.

This question is in favor to help to many people to find the proper way to estimate the Magento upgrades.

The question:

I am interested to know how do you measure the needed time for Magento upgrade? I guess, that most of you had hard time to answer on the client's question: "How long it will take to upgrade my Magento store?"

Usually the client needs to hear just a number for e.g.: "It will take X hours and it will cost Y bucks."

The main idea behind the question is about the technical side and what do you check as developer to make your own calculations for Magento upgrades.

I created the next check list, just for my own calculations:

• Is the Magento core touched?
• Is the Magento DB schema touched?
• Do we have inconsistent data in the DB?
• How many custom extensions are installed in local and community code pool?
• Are the custom extension compatible with the latest version of Magento?
• Did the theme developer used local.xml file for the the layout directives, or just copied xml files from the base/default/layout to the layout directory of the custom theme?
• Do we have deprecated layout directives / block methods in the layout xml files?
• Have I developed this Magento shop?

Do you think, that I am missing something and if yes, would you like to share with me and the community your additional points for the check list?

Answer 1

Estimating Magento upgrade is a process of collecting information about the modifications applied to the installation you are about to make up-to-date, checking if those modifications can cause a problem and then evaluating how much time is required to work around them.

All modifications can be literally divided into off-core and in-core.

Off-core modifications are those which will not be overwritten with upgrade. Those are 3rd-party extensions, core files put into local scope (app/code/local/Mage) and a custom theme.

In-core modifications are applied directly on Magento core files (app/code/core), localization files (app/locale/en_US), core templates and some things like javascripts, external libraries which are rarely customized nevertheless have to be taken into consideration.

Off-Core Modifications

3rd Party Extensions

During upgrades 3rd party extensions are the main source of issues. Which means more extensions you have more time you will need to analyze them.

The first thing to check is if the functionality provided by the extension is not yet implemented in a version of Magento you are upgrading to. For example some extensions like Yoast_CanonicalUrl, Mxperts_CustomerAddress or Fontis_Wysiwyg were widely used in Magento 1.3.x.x and older but now are part of core Magento functionality and no longer required.

Then it is a good idea to check (ask your customer) if you really need all those extensions you have. There might be some extensions you installed but never really used. So at this point it is good to make a sort of cleanup.

Then an important thing to check is a compatibility of each of remaining extensions with a version of Magento you are upgrading to. In case some extensions are not compatible and no similar extensions are available you will have a hard choice of either losing some functionality or modifying existing extensions to make them compatible.

Note: Don’t modify 3rd party extension directly but create a new extension which will extend an outdated one and then set a dependency in a bootstrap XML of new extension.

After all those done the actual analysis of each of remaining extensions can be provided. It shall always start with examination of etc/config.xml file. There are 3 things to look for:

• Class rewrites is not a clean technique by itself but in some cases there is no other way around. So if rewritten class was changed in the new version of Magento this could be a potential issue.
• Layout updates will less likely cause a problem with your upgrade but still if extension is referencing a block which is deprecated in a newer Magento version you will have to work this around.
• SQL updates are highly underestimated source of problems during upgrades. The issue happens when 3rd party extension is creating a foreign key referencing to some field in default Magento table. As result this field is locked from modifications. And then if native install script will try to update this field it will fail silently. After that every next install script referencing to to this field will crash your upgrade.

app/code/local/Mage

After you finished with your extensions it’s time to take a look at your app/code/local/Mage directory. Here you will find modified core files moved into a local scope. Each of them will surely cost you some grey hair because you never know (if it was not you who put them there) what was modified there and for what reason. So you have to compare each of them with an origin and migrate added functionality to correspondent file of the new version.

Custom Theme

The last bunch off-core modification is the custom theme. This may seem to be not a big deal but in fact this is a grey area. Magento base theme is being modified from version to version and each custom theme has to mimic some of those modifications. Unfortunately there is no silver bullet to determine what to look for and what have to be migrated. So just be prepared for some major surprises and minor nitpicking after your upgrade.

In-Core Modifications

In the perfect world there are none. But when you got a Magento installation after it has been abused by third-party developers, who are offering much for cheap you can expect anything. So in-core modifications are those which will be overwritten during the upgrade process. In most cases it will not produce any errors but as a result you will lose the functionality that was added in such a brutal way.

The only way to detect in-core modifications is to compare all files of your Magento installation with a clean files of the same version. I recommend doing it with git. Why? Simply because it will handle all newlines and whitespaces nicely.

Even if your Magento installation is not under git you can still copy your files into a separate directory and then run git init. Then make initial commit, copy “clean” Magento files over and run git status. You will get something like this:

Now depending on the number of modified files you can run git diff on each file or on the whole batch at once. This will give you a comprehensive reference of all in-core modifications made. If you have any git visualisation such as phpStorm the life is way much easier to you:

I suggest to do git diff > changes.txt so you will always have a list of modifications by hand.

Having the list of core modifications you can estimate what have to be transferred into new version and how much time will be required to do so.

Now I would like to give some advises for an actual upgrade. This process is well documented so I will not write what commands to run and where to click. However I want to make an accent on several important things:

• We are assuming that you are upgrading in your development environment. Running upgrade at your production server is a suicide.
• Don’t let them change anything in production while you are upgrading. Put your Magento under version control or even temporary lock files from writing.
• Disable all 3rd party extensions but note which ones were initially disabled so you will not enable them afterwards.
• Check if there is a Magento cleanup script running on the server. Otherwise truncate all tables starting with dataflow_*, log_*, report_*.
• Revert to default theme on upgrade time.

After upgrade script completed:

• Referencing the changes.txt you made before migrate all in-core modifications which are really worthy migrating.
• Migrate app/code/local/Mage modifications found before upgrade.
• One by one enable 3rd party extensions.
• Put back your theme and comprehensively compare the result with production server.
• Deploy to production once you are happy with the result.

Conclusion

I know this all sounds scary but if you are upgrading regularly, keeping your core clean and installing extensions only from vendors you really trust and only if you really need them you will not face most of the hardships described in this article. Keep your Magento EcoSystem healthy and you will be rewarded.

Post Scriptum

In very complicated cases it makes sense to start all over with a fresh install of latest Magento and migrate your store theme and functionality step-by-step. This will definitely take time but in the end you will have a healthy Magento system with your full awareness of what is going on.

Answer 2

Generally speaking, the Core code should never be touched while developing. There are many mechanisms in Magento to allow you to work around any issues, even internal bugs. That being said, there are other issues to look out for as well.

1. Do any community or local modules override core code (Can be searched in the modules folder for <rewrite>, and it is bad practice as they really should use non-obtrusive code such as events )
2. Magento tries to keep the code backwards compatible, but sometimes the code does change significantly (Can be found here), if the backwards incompatible changes are many, that might add to the process.
3. Is it easy/possible to duplicate the code into a development environment. if it is, simply running the upgrade and testing might be all that's needed.
4. Is the upgrade needed? Are there features in the new version that the client can't leave without? Any security issues (many times Magento provides back-patches as well)

As far as the template is concerned, from previous experience I can tell you that it barely breaks, unless the developer went crazy on the template coding (Which should be in blocks anyways).

Answer 3

Here are some things to keep in mind:

• Check if theme is compatible (check to see if there is extensive coding in the template files - sometimes junior developers do this)
• Check how the media is being stored (are they using CDN's etc)
• Check if there is any special caching methods in place (APC Memcached etc)

One way to handle this type of client request, is to do an estimate review.

This entails telling the client that you will spend some (billable) time looking at it, and will give them a more accurate timeframe/cost for doing the project.

Going this route benefits both you and the client.

The client usually will feel more confident in your estimate, and will respect your recommendations, which in turn benefits you, by reducing possible stress.

Estimate review:

The actual estimate review would be something along these lines:

• Dump the live database and import it on a development machine
• Copy over the magento files from their live machine to your dev machine
• Make sure all is well and working
• Attempt the upgrade and do some initial testing to see what might be breaking

This process should take an average of two billable hours, and will give you much necessary insight into the system at hand.

Answer 4

We've done various upgrades on Magento CE, the worst being from 1.3 to 1.7 which took us almost 4 full days. The initial estimate was 1-2 days. I guess that upgrading from 1.x to 2.x will be a similarly huge undertaking and even if migration tools will be provided by the core team, it might be cleaner to just start from scratch.

Answer 5

I want to add one thing to the excellent answers given above:

• Check if a VCS and proper deployment process is in place.

I won't do an upgrade without proper processes behind it and the possibility to step back when problems occur (even more if I didn't work on the site before). About 90% of the clients approaching us for a Magento upgrade (which haven't been our clients before) only do have a live environment without any testing/staging, VCS whatsoever in place.

Answer 6

Integration with other entities is an important thing to ask about. This is something you might not be able to spot by looking at the site - it's common for clients to have back-end systems fetching orders via the Magento API, for example, and if you don't handle continuity of that integration while upgrading you can get into a mess.

When you're reviewing components, look out for ones that talk to other systems - each of these is going to be hairy to test because you don't want to accidentally push test data to a live system. Often there's a test endpoint in existence that was used by the original developers, but you may not have that information any more when upgrading.