如果您熟悉「構建一個可以扔掉」這個短語，那麼我們似乎已經這樣做了;我們正在達到我們的在線應用版本1的限制。現在是時候通過清理東西：實施較大的系統更改
什麼是使這種轉變發生的最佳方式？
我們希望避免把所有的用戶都拋到一個新的系統上（一旦它完成）......他們會嚇壞了，我們無法處理呼叫負載。我們的用戶可以從技術上熟練的二手寫軟件類型到不知道HTML的軟件類型。
我們是否應該在確保這個新設計充分解決了版本1中的問題之後，開始對系統進行新的「安裝」並逐漸將用戶移至其上？
我們是否應該（以某種方式）遞增地改變我們系統的每個模塊，然後階段？這可能很困難，因爲數據庫佈局會改變，導致不得不調整「核心代碼」和幾個周邊模塊的代碼。
是否有一組使用尖端版應用程序的可信患者「測試者」客戶端？ （這裏的目標是獲得反饋並測試新系統上的錯誤）
任何其他建議？第一手經驗？
恐怕這個答案要看情況。這取決於應用程序的種類和您擁有的用戶類型。在不知道系統是什麼以及版本變化的範圍的情況下，很難提供答案。
這就是說，有一些經驗法則。
首先，避免大爆炸發射。任何系統的啓動都會遇到問題。這個行業充滿了各種各樣的項目，人們認爲爆炸發射是一個好主意，只是因爲出現問題纔將發射推遲到最後。 Cuil是大爆炸發射最近引人注目的因果關係。
爲了使初期問題易於管理，您需要最初與少量用戶合作，然後慢慢增加用戶數量。其次，你必須絕對必須積極做的事情是把用戶放在首位。用戶應該儘可能少地使用系統的V2。理想的工作量將爲零。
這意味着，如果您選擇將用戶從一個系統緩慢遷移到另一個系統，負責確保遷移其所有數據和設置。例如，不要做任何愚蠢的事情，比如告訴用戶他們必須在12/09/2008之前對所有記錄使用V1，之後對所有記錄使用V2。
發佈V2的重點應該是讓用戶的生活更輕鬆，不會讓它變得更加困難。
第三，有一個測試程序。這甚至適用於Intranet應用程序。開發一個應用程序就像Newton-Raphson找到多項式根的方法。您可以猜測用戶需要什麼，將其交付給用戶，用戶提供反饋，並且緩慢但確實地每次迭代都會使您更接近解決問題的方案。
一個測試版程序將幫助您找到根源要快得多，而不是僅僅讓新版本對人們進行評論，而無需時間對其進行評論。 Betas幫助您的用戶儘早上車，並讓他們感受到這一過程;我不能強調這一點的重要性。
我們剛剛完成了一項全新的客戶關係管理系統，讓我告訴你這樣做是一個糟糕的主意：這對我的團隊和我們的客戶來說是非常痛苦的。
我會盡全力去做逐步發佈，即使這意味着要做更多的工作。你會感激不已，因爲你不必爲了讓所有東西都搬走而進行英勇的努力，而且你的客戶會很欣賞能夠一次介紹產品的能力。
希望有幫助！
聽起來像增量式重新架構應該是您敏捷的首選選項。
我從來沒有在一個Web應用程序上做過它，但我經歷了一些相當激進的客戶端應用程序更改，這些更改是逐步完成的。如果您事先投入一點時間，以確保各項工作以相當合理的方式排序，那麼它可以很好地工作。如果您還沒有它們，那麼對重構輔助工具的小投資將非常有幫助。如果您使用.NET，我可以親自推薦jetBrains Resharper，如果您是基於Java的，我相信IntelliJ IDEA包含類似的功能。
我同意Esteban漸進版本是最好的。這就像重塑一棟房子：最初似乎是一個好主意。但意味着你必須事先計劃好一切，僱傭一批承包商並搬出去。然後，計劃中的某些變化或承包商消失，並且你希望保存的所有時間都消失了。同時，漸變讓每個人都有機會停下腳步並思考。有時你可以避免以後的變化，當以前的變化比你計劃的更好。
我工作的系統有一個巨大的縮放問題。我們列出了所有我們認爲需要的變更，並以可能的影響優先考慮這些變更。然後，我們開始一次進行一次更改。關於列表的一半，我們發現我們已經解決了縮放問題。我仍然有這份名單，但我可能永遠不需要完成它。我可以自由添加功能並解決其他問題。
當然，有些時候最好是咬一口子彈，並把整個事情推倒。但這比人們傾向於相信的要少得多。對於關鍵的操作系統，「拆卸」決定可能是致命的。看看大家認同的大型政府項目必須進入現代計算時代，但不能因爲一些重要的服務將會丟失。如果哲學逐漸發生變化，那麼他們可能會一次性完成現代化。