如果您熟悉“建造一个扔掉”这个短语，那么我们似乎已经做到了；我们正在达到我们在线应用程序版本 1 的限制。是时候清理一下了：
实现这种转变的最佳方式是什么？
我们希望避免将所有用户都扔给一个新系统（一旦完成）......他们会吓坏了，我们无法处理呼叫负载。我们的用户涵盖范围广泛，从技术熟练的用于编写软件的类型到那些不知道 HTML 是什么的用户。
在我们确保这个新设计充分解决了版本 1 的足够问题之后，我们是否应该开始一个新的系统“安装”并逐渐将用户转移到它？
我们是否应该（以某种方式）逐步更改系统的每个模块并进行阶段化？这可能很困难，因为数据库布局会发生变化，导致必须调整“核心代码”和几个周围模块的代码。
拥有一组使用尖端版本的应用程序的受信任、耐心、“beta 测试员”客户是否很常见？（这里的目标是获得反馈并测试新系统上的错误）
还有什么建议吗？第一手经验？
恐怕答案取决于情况。这取决于应用程序的类型和您拥有的用户类型。在不知道系统是什么以及版本更改的范围的情况下，很难提供答案。
也就是说，有一些经验法则。
首先，避免大爆炸。任何系统的启动都会出现问题。该行业充斥着人们认为轰轰烈烈的发射是个好主意的项目，只是因为出现问题而使发射陷入困境。Cuil是近期大爆炸发射的一个备受瞩目的因果关系。
为了使初期问题易于管理，您首先需要与少量用户合作，然后慢慢增加用户数量。
其次，你绝对必须积极做的事情就是把用户放在第一位。用户应该做尽可能少的工作来使用系统的 V2。理想的工作量为零。
这意味着，如果您选择将用户从一个系统缓慢迁移到另一个系统，您有责任确保迁移他们的所有数据和设置。例如，不要做任何愚蠢的事情，比如告诉用户他们必须对 12/09/2008 之前的所有记录使用 V1，对之后的所有记录使用 V2。
发布 V2 的目的应该是让用户的生活更轻松，而不是让它变得不必要地变得更加困难。
第三，有一个测试程序。这甚至适用于 Intranet 应用程序。开发应用程序很像 Newton-Raphson 的求多项式根的方法。您猜测用户想要什么，将其交付给用户，用户提供反馈，并且每次迭代都会缓慢但肯定地使您更接近问题的解决方案。
一个 beta 程序将帮助您更快地找到根源，而不是仅仅将新版本强加给人们而没有时间让他们对更改发表评论。Beta 有助于让您的用户更早地加入进来，并让他们感到参与到流程中；其中的重要性我怎么强调都不为过。
我们刚刚为我们的用户完成了一个全新的 CRM 系统，让我告诉你，这样做是一个可怕的想法：这对我的团队和我们的客户来说都是非常痛苦的。
我会尽一切可能进行逐步发布，即使这意味着做更多的工作。您将心存感激，因为您不必费尽心机就可以让所有东西都动起来，而且您的客户会很欣赏能够一次次了解产品的能力。
希望有帮助！
我同意Esteban的观点，即逐步发布是最好的。这就像改建一所房子：一开始，把它搞定似乎是个好主意。但这意味着你必须提前计划好一切，雇佣一堆承包商然后搬出去。然后计划中的某些变化或承包商消失了，您希望节省的所有时间都消失了。同时，渐进式的变化让每个人都有机会在步骤之间停下来思考。有时，当早期更改的效果比您计划的要好时，您可以避免以后的更改。
我在一个存在巨大扩展问题的系统上工作。我们列出了我们认为需要的所有更改，并根据可能的影响对它们进行了优先排序。然后我们开始一次进行一项更改。大约在列表进行到一半时，我们发现我们已经解决了缩放问题。我仍然有清单，但我可能永远不需要完成它。我可以自由添加功能并解决其他问题。
当然，有时最好硬着头皮把整个事情拆掉。但这比人们倾向于相信的要少得多。对于关键的操作系统，“拆除”决定可能是致命的。看看每个人都同意必须将其带入现代计算时代的大型政府项目，但不能这样做，因为一些重要的服务将会丢失。如果哲学是逐渐改变的，也许它们会一次一个地被现代化。
听起来增量式重新架构应该是您选择的敏捷流行语。
我从来没有在 Web 应用程序上做过，但我经历了一些相当激进的客户端应用程序更改，这些更改是逐步完成的。如果您预先花一点时间来确保以相当合理的方式对工作进行排序，那么它可以很好地工作。如果您还没有良好的重构辅助工具，那么对它们进行少量投资将非常有帮助。如果您使用的是 .NET，我个人可以推荐jetBrains Resharper，如果您是基于 Java 的，我相信 IntelliJ IDEA 包含类似的功能。