估计Magento升级是一个过程，该过程收集有关您将要进行的最新安装上的修改的信息，检查这些修改是否会引起问题，然后评估解决这些问题所需的时间。
从字面上看，所有修改都可以分为内核外和内核内。
核心外修改是指那些升级不会覆盖的修改。这些是第三方扩展，放置在本地范围内的核心文件（app / code / local / Mage）和自定义主题。
内核内修改直接应用于Magento 核心文件（应用程序/代码/核心），本地化文件（应用程序/语言环境/ en_US），核心模板以及诸如javascripts之类的东西，但仍需考虑很少自定义的外部库。
核外修改
第三方扩展
升级期间，第三方扩展是问题的主要根源。这意味着更多的扩展，您将有更多的时间来分析它们。
首先要检查的是，您要升级到的Magento版本是否尚未实现扩展提供的功能。例如一些扩展喜欢Yoast_CanonicalUrl，Mxperts_CustomerAddress或者Fontis_Wysiwyg被广泛使用在Magento 1.3.xx及以上，但现在的核心Magento的功能的一部分，不再需要。
然后，最好检查（询问您的客户）您是否真的需要拥有的所有这些扩展。您可能安装了一些扩展程序，但从未真正使用过。因此，此时最好进行某种清理。
然后要检查的重要一件事是，每个其余扩展与要升级到的Magento版本的兼容性。如果某些扩展名不兼容并且没有相似的扩展名可用，您将很难选择丢失某些功能或修改现有扩展名以使其兼容。
注意：请勿直接修改第三方扩展名，而是创建一个新扩展名，该扩展名将扩展已过期的扩展名，然后在新扩展名的引导XML中设置依赖项。
完成所有这些操作后，便可以提供每个剩余扩展的实际分析。它应始终从检查etc/config.xml文件开始。有3件事情要寻找：
- 类重写本身并不是一种干净的技术，但是在某些情况下，别无选择。因此，如果在新版本的Magento中更改了重写的类，则可能是一个潜在问题。
- 布局更新不太可能导致升级问题，但是如果扩展引用的块是在较新的Magento版本中弃用的块，则必须解决此问题。
- 在升级过程中，SQL更新被严重低估了。当第三方分机正在创建引用默认Magento表中某个字段的外键时，就会发生此问题。结果，该字段无法修改。然后，如果本机安装脚本将尝试更新此字段，它将无提示地失败。之后，每个下一个引用此字段的安装脚本都将使您的升级崩溃。
应用/代码/本地/法师
在完成扩展名之后，是时候查看app/code/local/Mage目录了。在这里，您会发现已修改的核心文件已移至合并local范围。他们每个人肯定会花掉您一些白发，因为您永远不知道（如果不是您将它们放在那儿）在那里修改了什么以及出于什么原因。因此，您必须将它们中的每一个与来源进行比较，然后将添加的功能迁移到新版本的对应文件中。
自订主题
最后一堆非核心修改是自定义主题。这似乎没什么大不了，但实际上这是一个灰色区域。Magento基本主题在各个版本之间进行了修改，每个自定义主题都必须模仿其中的一些修改。不幸的是，没有确定要寻找什么和必须迁移什么的灵丹妙药。因此，只需为升级后的一些重大惊喜和轻微挑剔做好准备。
核心修改
在理想世界中，没有任何东西。但是，当Magento安装被第三方开发人员滥用后，他们以便宜的价格提供了很多东西，那么您可以期望得到安装。因此，核心修改是在升级过程中将被覆盖的修改。在大多数情况下，它不会产生任何错误，但是结果，您将失去以如此残酷的方式添加的功能。
检测内核内修改的唯一方法是将Magento安装的所有文件与相同版本的干净文件进行比较。我建议用git来做。为什么？仅仅是因为它将很好地处理所有换行符和空格。
即使您的Magento安装不在git下，您仍然可以将文件复制到单独的目录中，然后运行git init。然后进行首次提交，复制“干净的” Magento文件并运行git status。您将获得如下内容：
现在，根据修改后的文件数，您可以一次git diff在每个文件上或整个批次上运行。这将为您提供所有核心修改的全面参考。如果您有任何gitStor可视化版本（例如phpStorm），那么生活就容易得多：
我建议您这样做，git diff > changes.txt这样您总是可以手动获得一份修改清单。
有了核心修改的列表，您可以估计必须将哪些内容转移到新版本中以及需要多少时间。
现在，我想为实际升级提供一些建议。这个过程有充分的文档记录，因此我不会编写要运行的命令和单击位置。但是，我想强调几个重要事项：
- 我们假设您正在开发环境中进行升级。在生产服务器上运行升级很容易自杀。
- 升级时，不要让他们在生产中进行任何更改。将您的Magento置于版本控制下，甚至禁止写入临时锁定文件。
- 禁用所有第3方扩展，但请注意最初禁用了哪些扩展，因此以后将不再启用它们。
- 检查服务器上是否正在运行Magento清理脚本。否则，截断所有表开始
dataflow_*，log_*，report_*。
- 在升级时恢复为默认主题。
升级脚本完成后：
changes.txt在迁移所有真正有价值的核心修改之前，请先参考您所做的修改。- 迁移
app/code/local/Mage升级前发现的修改。
- 一对一启用第三方扩展。
- 放回主题，然后将结果与生产服务器进行全面比较。
- 对结果满意后，将其部署到生产中。
结论
我知道这听起来很可怕，但是如果您定期进行升级，保持核心整洁并仅从您真正信任的供应商处安装扩展，并且仅在确实需要它们时，您才不会面对本文所述的大多数困难。保持您的Magento生态系统健康，您将得到回报。
圣经后
在非常复杂的情况下，重新安装最新的Magento从头开始并逐步迁移商店主题和功能是有意义的。这肯定会花费一些时间，但是最终您将拥有一个健康的Magento系统，并且完全了解正在发生的事情。