早在2013年，当组织仍在从以前的版本过渡到BI4.0时，考虑到Matthew Shaw撰写的关于此类实践的文章（此处），许多工程师肯定对升级实践有"创造性"。在这篇文章中，他告诫不要简单地忽略对CMS数据库的潜在更改的升级方法，并最终得出结论，最佳实践是就地升级。

尽管我们确实同意就地升级是一种非常好的方法，并且绝对优于他在文章中描述的"创造性"方法，我们还认为，支持的替代方法也有优点，即新的部署方法，即从头开始构建新的BI系统，内容通过支持的接口从当前系统迁移（4.x到4.x+的升级管理）

就地升级的一个缺点是强制从您升级第一个环境的那一刻起，组织就陷入了开发冻结状态，这可能就是开发。在那个时候，微博淘客，由于版本差异，不能再将其开发内容提升到产品中。即使您首先升级了另一个环境（例如，测试），开发生命周期中的某一点也会受到版本差异的影响。为了尽量减少这种影响，可以先升级测试，然后被迫在另一个环境（可能是开发环境）中运行测试，这在任何情况下都会对该生命周期产生影响，只是方式不同（在这种情况下，只有在测试完成后才能开始新的开发）。

仅此一点就表明，就地方法更适合小型部署，小型部署可以快速适应其开发生命周期过程中的干扰，并容忍这种类型的开发冻结。

大型部署，智能建站软件，具有多个服务器和专用的BI开发人员，测试团队等可能会发现这种影响不可接受。

就地升级也会带来相当高的风险因素：如果升级出现问题（任何人，任何人？）没有后备系统。如果ugprade问题发生在开发环境中，那么在这里，较小的组织也可以在测试系统或其他形式的临时即兴创作中调整和运行它们的开发。但是，如果只在生产系统中检测到特定的有问题的问题怎么办？

以下是升级过程中检测到的一些问题示例：

CMC和BI Launchpad在应用建议的修补程序后关闭且无法访问在BW上开发WebI非常慢（5分钟来显示连接内容），以至于不能再开发了计划作业无法运行Lumira客户端无法写入存储库

所有这些错误都来自BI4.2升级，其中一些没有解决方法。然后呢？在您扩大开发冻结的同时，组织是否愿意承担系统关闭几天直到修复的风险？如果这些问题在生产中发生呢？

当然，我听说你认为，我可以简单地卸载（Windows）部署，公众号返利系统，然后回到原来的状态，对吗？答案是：有时。升级过程中有某些问题可能无法通过回滚安装（卸载）来修复。卸载没有解决问题。即使在可能的情况下，返利购，降级BI的最新版本也需要更改许可证密钥，这在一定程度上使过程复杂化了

现在您一定在想"备份可以工作"。备份当然可以工作，只要它们做得好。许多组织依靠RDBMS备份计划备份BI服务器，云产品，而忽略CMS数据库。这迫使返回点目标（RPO）指向两个文件（服务器文件或数据库）中最早的一个，如果它们之间的差异很大，CMS中会出现一些不一致的情况，必须通过存储库诊断工具来解决。在这一点上，所有从就地升级所期望的简单性都被增加的复杂性所取代。

一个新的部署可能会有上面提到的完全相同的错误，但不同的是，它们不会对现有的业务流程产生影响，因为当前版本仍在工作。变更和开发冻结只有在迁移过程开始时才会开始，即使这样，如果需要，第二个迁移波也可以捕获在开发冻结期间创建的对象。

由于消除了干扰用户的风险，而不是灭火，项目团队可以集中精力构建新环境并解决问题，以便在切换到新版本时提供高质量的部署。对开发人员、测试人员、业务用户和分析人员的干扰将是最小的，甚至是零。

这种方法的优点是允许对安全设计进行更改，而不会影响当前用户

当然就地升级是方便和容易的，因为您不必担心数据库驱动程序，而且安装所需的时间更少。但也有一些不利因素，也有更高的风险要考虑，这在"新部署"方法中几乎被消除了，BI经理和管理员应该考虑这些因素，因为它们不是很明显，在计划升级时很容易被忽略。简而言之，如果您正在寻找以下优势，请考虑新的构建：