如果你熟悉“建立一个扔掉”的短语，那么，我们似乎已经这样做了;我们已达到在线应用程序版本1的限制。现在是时候通过以下方式清理：
实现这种转变的最佳方式是什么？
我们希望避免将我们所有的用户都扔到新系统上（一旦完成）......他们会惊慌失措，我们无法处理呼叫负载。我们的用户可以运行从技术上熟练的用户到写入软件类型到不知道HTML是什么的用户。
我们是否应该开始对系统进行新的“安装”，并在我们确保此新设计充分解决版本1的问题后，逐渐将用户转移到该系统上？
我们（以某种方式）是否应该逐步改变我们系统的每个模块，并且相位？这可能很困难，因为数据库布局会发生变化，导致必须调整“核心代码”和几个周围模块的代码。
使用最先进的应用程序版本，拥有一组值得信赖，耐心，“beta测试”的客户是否常见？ （这里的目标是获得反馈并测试新系统上的错误）
还有其他建议吗？第一手经验？
答案 0 :(得分：2)
答案，我担心，这取决于。这取决于应用程序的类型和您拥有的用户类型。在不知道系统是什么以及版本的变化范围的情况下，很难提供答案。
那说，有一些经验法则。
首先，避免大爆炸发射。任何系统的启动都会遇到问题。这个行业充斥着人们认为爆炸发射是一个好主意的项目，只是为了解决问题以使发动机瘫痪。 Cuil最近引发了大爆炸的高调因果关系。
为了使出牙问题易于管理，您最初需要与少量用户合作，然后慢慢增加用户数量。
其次，你必须绝对必须做的事情是把用户放在第一位。用户应该尽可能少地工作以使用系统的V2。理想的工作量为零。
这意味着如果您选择将用户从一个系统缓慢迁移到另一个系统，您负责确保迁移所有数据和设置。例如，不要做任何愚蠢的事情，比如告诉用户他们必须在12/09/2008之前使用V1表示所有记录，在之后的所有记录都使用V2。
释放V2的重点应该是让用户的生活更轻松，而不是让它变得更加困难。
第三，有一个测试计划。这甚至适用于Intranet应用程序。开发应用程序就像Newton-Raphson找到多项式根的方法一样。您可以猜测用户想要什么，将其交付给用户，用户提供反馈并缓慢但肯定地每次迭代都会让您更接近解决问题的方法。
测试版程序可以帮助您更快地找到根目录，而不仅仅是将新版本强加给人们，而没有时间让他们评论这些更改。 Betas帮助您的用户提前入住，让他们感觉自己被包含在流程中;我不能强调的重要性。
答案 1 :(得分：1)
我们刚刚完成了对用户的全新CRM系统，让我告诉你这样做是一个可怕的想法：这对我的团队和我们的客户来说非常痛苦。
我会通过各种可能的方式来逐步发布，即使这意味着要做更多的工作。你会感激不尽，因为你不需要经过英勇的努力就能让一切都动起来，而且你的客户会很高兴能够有时间介绍产品。
希望有所帮助！
答案 2 :(得分：1)
我同意Esteban渐进式发布是最好的。这就像重新装修一座房子：最初将它看作是一个好主意。但这意味着你必须提前计划一切，聘请一大堆承包商并搬出去。然后计划中的某些变化或承包商消失了，你希望保存的所有时间都消失了。同时，渐进的变化让每个人都有机会在步骤之间停下来思考。有时，当先前的更改比您计划的更好时，您可以避免以后的更改。
我在一个存在巨大扩展问题的系统上工作。我们列出了我们认为需要的所有变更，并通过可能的影响对其进行优先排序。然后我们开始一次做一个改变。大约在列表的一半，我们发现我们已经解决了扩展问题。我仍然有列表，但我可能永远不需要完成它。我可以自由添加功能并解决其他问题。
当然，有时候最好咬紧牙关并撕下整个东西。但这并不像人们所认为的那么普遍。对于关键的运营系统，“拆除”决策可能是致命的。看看每个人都同意的大政府项目必须被带到现代计算时代，但不能因为一些重要的服务将会丢失。如果哲学是逐渐改变的话，也许它们可以一次现代化。
答案 3 :(得分：0)
听起来增量重新架构应该是您选择的敏捷口号。
我从来没有在Web应用程序上完成它，但我已经完成了一些相当激进的客户端应用程序更改，这些更改是逐步完成的。如果你预先投入一点时间来确保工作以一种相当合理的方式排序，那么它可以很好地工作。如果你没有那么好的重构辅助工具的小额投资将非常有用。如果您使用.NET，我个人可以推荐jetBrains Resharper，如果您是基于Java的，我相信IntelliJ IDEA包含类似的功能。