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