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.
Best Answer
For migration from magento 1 to magento 2 you have to migrate or convert following details a) Data b) Theme c) Customization you did d) Extension
For more information on this please follow. http://devdocs.magento.com/guides/v2.0/howdoi/migrate/migrate.html
1) Export and Import your Customers, Orders and Product Details.
2) Use any comparison tools like Beyond Compare to check if is there any core files modification exist. if exist make a note of it.
3) Compare the third party extension if you have modified it or not and make a list of it.
4) Check whether you have directly created database tables (Without using Extension script). if exist make a note of it.
5) Check Availability of Third party extension available for magento 2. if you not exist you have to convert it yourself.
6) Install Magento 2 Latest version and Import the data
7) Install third party extension available for magento 2, which you have already installed in magento 1. Modify it according to the result of Step 3.
8) Build Extension by yourself which are not available or you have build for your own purpose.
9) Write Custom Plugin for the report you get from step 2 and a plugin for orphan database tables.
Hope you understand the concern.
Thanks