简短的答案

这要看情况。

迁移策略将受到源本身的质量和内容以及体系结构和工作流的影响。没有"银弹"可以使其发挥作用。

更长的答案

应该怎么做

您可以自动升级所有暂存站点，运行所有单元测试，如果它们都通过 - 运行验收测试。修复出现的问题，直到您可以通过所有测试。然后让你的QA人员确保一切真的100%正常。整个过程主要由您的持续集成系统/框架运行。

当过渡环境一切正常时，您可以关闭每个站点进行维护，将更新的代码部署到生产环境，升级服务器的软件，然后备份站点。

你将(很可能(必须如何做

由于您的软件都没有任何单元/验收测试，没有最新的规范，甚至没有持续集成系统的概念，因此您将不得不以艰难的方式进行：

'step 1' take a survey of different servers setups on which your projects 
         are deployed (if you have all project on single box with 
         virtual-hosts, you can skip this bit )
'step 2' find somewhere a computer, which can temporary act as local server
<foreach setup>
    'step 3' install/configure this temporary server to be exactly like 
             the "setup"
    <foreach project on that setup>
        'step 4' BACKUP ALL THE STUFF
        'step 5' copy the latest source and DB from the production server
        'step 6' upgrade the software
        'step 7' see what has *blown* up and fix what you can find    
        'step 8' pass to the QA team 
        'step 9' store the source
    </endforeach project>
    'step 10' take the server with this configuration down for maintenance
    'step 11' upgrade software on the server
    'step 12' deploy all the projects from this server 
    'step 13' prayer (optional)
<endforeach setup>

这有点像"简短"版本。基本上，您将不得不逐个服务器，在本地克隆它，然后升级，修补项目。然后升级每台服务器并放置修补的版本。还有希望。

你应该升级吗？

_{客户不会为此付费。}

由于你有~50个不同的项目，你必须调查它是否值得花时间和金钱。经过这样的分析，您可能会发现，对于企业来说，将大多数项目标记为"遗留">并仅将服务器升级到最新的5.2.x会更有意义。那就别管它了。

当然，即使您决定不升级大多数项目，也会有一些项目需要它。特别是具有持续合同的项目，为公司带来了稳定的收入来源。

我建议开始升级那些摇钱树项目，因为无论如何你都必须这样做。然后，根据这种经验，您可以计算其余"投资组合"的成本。

下次呢？

PHP 5.4 已经出来了(在上次编辑时，5.5 已经到来了(。到今年年底，大多数公司将面临一个问题：">是时候开始使用5.4了吗？有些早，有些晚。您使用的框架和 CMS 也有获取更新的趋势。

底线：您的公司作为一个整体应该开始研究简化此过程的方法。

当您升级到 PHP 5.5 并且mysql_*函数开始显示E_DEPRECATE警告时呢？请参阅mysql_affected_rows()文档中的红色框。这不是一次性的事情。

投资实现更好的部署策略(涉及单元测试和持续集成(可能是明智的。

---

_<rant>

_{php的开发人员有没有想过这个问题？许多(流行的(功能只是贬值，给像我们这样的人带来了很多工作。}

_{已弃用的功能和功能已在文档中标记为此类多年。例如，自从我开始学习 PHP 以来，不应使用ereg()和通过引用传递对象的通知就一直存在。弃用警告主要影响 PHP4 代码库(在这种情况下，您的问题有点不诚实(。}

_{我不明白多年来在社区中被接受的执法做法如何"造成大量工作"。}

_</rant>

首先，通过软件包管理系统(yum，apt-get等(将程序存储在软件包(RPM，DEB等(中，并正确设置依赖项信息。

然后，通过具有适当的发布链和集成步骤来测试升级依赖项时代码是否中断。像 Jenkins 这样的 CI 服务器可以运行你的自动化测试并为你构建包。

如果有问题，它们会很快出现，您可以开始修复它们。使用您通常的内部流程来确定错误的优先级和修复(请注意，值得关注给定包中的依赖项升级引入的所有错误，而不是通过并行处理十几个程序来分散工作(。

显然，您应该遵循建议的升级实践; 其他答案正在提供它们。

需要采取一些过程和程序步骤;我在那里没有具体建议，事实上 tereško 的回答非常好恕我直言

但是，在必须更改代码库本身的情况下，您可能有一个选择：

• 您可以手动完成所有操作(这似乎是隐含的假设(。 这并不奇怪。
• 您也许能够自动应用更改。

纯手动方法要求您发现所有类型的不兼容性(语言更改、框架更改、基础结构替换等(，弄清楚如何大致修复它们，然后在适当的情况下应用每种修复类型。 最后一部分非常昂贵，因为它需要您检查每一行代码，如果错误，请修复它。

自动更改无助于发现问题或制定解决方案。 但是，一旦你弄清楚如何解决问题，它可能有助于在所有必要的地方应用该解决方案。

每个问题都需要一种"如果你在代码中看到这个，把它改成那个"。 这个非正式的想法可以打包为程序转换，修改代码的正式规则。

我的公司提供了一个工具，DMS软件再造工具包，这是一个程序转换引擎。 它可以使用特定于语言的前端分析和转换多种计算机源代码;它有一个适合此任务的PHP前端(解析器/漂亮打印机(。 DMS是为这种任务而设计的，这就是为什么它的名字的一部分是"软件再造工具包"。 我们已经将它用于许多更令人讨厌的重新设计任务。

因此，我们的想法是将所需的更改打包为程序转换，并使用DMS之类的工具来应用它们。 编写修复代码中的问题的规则需要付出努力，但是一旦完成，DMS就可以可靠地应用这些规则。 因此，您投资于前几个系统(以调整和验证规则(，以使更新最后 48 个系统更有效率。

这不是灵丹妙药;你不能总是轻易地为你想要的东西写一个转换。 但是，当您要进行大量更改，并且想要在代码中进行这些更改时，使用工具尽可能可靠地执行尽可能多的更改比手动执行所有操作要好得多。

我想

这个列表：http://php.net/manual/en/migration53.incompatible.php 就是你需要担心的。

最好的方法是遵循 PHP 5.3 迁移指南(然后是 PHP 5.4(。

如果您使用的是像切诺基这样的替代Web服务器，则可以使用PHP的并行安装。如果由于操作系统中的安装限制而无法执行此操作，则始终可以使用chroot环境并更改php解释器的端口。

如果我必须更新 php 版本，我会向页面添加第二个域，例如使用新 php 版本的 updated.domain.com。普通用户不会看到任何区别。但不幸的是，这只有在您使用相对路径并且文件中没有硬编码域时才有效。