抽象分支讓呼叫端使用共同介面，新舊實作則可以同時保留，再依需要切換。如果要替換的是分開執行的新舊系統，就需要採取別的手法。

團隊可以先讓新系統接手一部分功能，其餘功能繼續由舊系統提供，再逐步擴大替換範圍。這種做法稱為 Application strangulation，也常稱為 Strangler Fig。後者是 Martin Fowler 採用的植物比喻，以植物逐步取代原樹的過程，描述新系統逐步取代舊系統。

以下沿用 Nathan 團隊的人物設定，另設一個客戶管理系統改版的假想情境。改版期間，舊系統仍須提供查詢與修改功能；團隊希望先交付完成的部分，不必等整套新系統完成才一起切換。

原本的客戶管理系統

使用者查看客戶清單時，瀏覽器會向網站送出 GET /customers。原本由舊系統確認使用者可以查看哪些客戶，讀取資料，再回傳清單畫面。使用者從清單開啟客戶資料，或新增、修改客戶時，也都由舊系統處理。

Elvina 負責新的客戶清單畫面，Mandy 負責查詢程式，Brent 準備部署環境。三人先選擇只供閱讀的清單功能作為第一步，新增、修改客戶及其他功能繼續留在舊系統。

這次替換保留原本的清單網址與查詢參數，也保留誰可以查看哪些客戶的規則。

如果把整份改版留在分支，等新系統全部完成才合併，新清單與舊系統介面在共同主幹上的整合與驗證就會延後。團隊需要讓新程式能分步整合，同時保留一般使用者原本的操作。

在共同入口選擇處理請求的系統

新清單即使已經部署，只要瀏覽器的請求仍送到舊系統，使用者看到的就還是舊清單。因此，Brent 在新舊系統前面安排共同入口，由它接收瀏覽器的請求，再依規則轉交給其中一個系統。

開始時，共同入口仍將所有請求送到舊系統，之後再逐項調整分流規則。

這次預計只將 GET /customers 交給新系統，其餘功能的請求仍交給舊系統。規則要一起判斷請求方法與路徑，不能只看到網址包含 customers，就把新增或修改客戶的請求一起轉走。

共同入口的分流規則需要和程式一樣保留版本。

透過舊系統讀取客戶資料

原本由舊系統一起處理查詢與畫面，換成新清單後，新系統也需要取得客戶資料。這一步先保留原本的資料儲存與寫入方式，由 Mandy 在舊系統提供讀取介面，讓新系統查詢清單需要的資料。

新系統提出查詢時，舊系統仍依經驗證的使用者身分判斷可讀取的資料範圍，再回傳清單所需欄位。Brent 與 Mandy 要確認兩個系統能配合登入與權限檢查，不能只因為使用相同入口，就認為原本的權限規則會自動適用。

清單功能切換後，新舊系統的分工與呼叫關係如下：

新系統不另外保存一份客戶資料，這一步可以先替換清單功能，保留原本的資料寫入方式。

新清單尚未開放，也能分步整合

Mandy 可以先完成舊系統的讀取介面，整合到主幹。Elvina 與 Mandy 再逐步整合新清單的畫面與查詢程式，Brent 則準備新系統的部署設定。這些步驟可以分開進行，不必等整份改版完成才一起合併。

新清單還沒開放，也要跟著舊系統的變更一起維護。例如，舊系統調整介面回傳的客戶欄位後，新清單的讀取與顯示就可能受到影響。相關程式都持續整合到主幹，團隊就能隨著這些變更一起驗證，不必等準備切換時才處理不相容的地方。

Brent 先在測試環境部署包含讀取介面的舊系統，再部署新系統。他另外準備供團隊使用的測試入口，將經過這個入口的 GET /customers 交給新系統，其餘功能請求仍交給舊系統。正式入口的規則保持不變，一般使用者繼續使用舊系統。

Elvina 與 Mandy 從測試入口登入，確認新清單的查詢結果，再開啟由舊系統處理的客戶資料頁面，最後返回新清單。這些操作都經過測試入口，驗證兩套系統是否能在維持原本登入與權限規則的情況下接續使用。

Brent 再把測試入口改回全部請求都交給舊系統，和兩人確認清單可以切回原本的畫面與操作。新舊頁面或切回流程若有問題，正式入口就先維持原本規則，等問題處理後再切換。

切換正式清單與處理失敗

Brent 將測試過的新舊系統版本部署到正式環境，先提供舊系統的讀取介面，再部署依賴它的新系統。

一般請求仍交給舊系統，Brent 另外在正式環境提供僅供團隊使用的測試入口，採用相同的分流規則。Elvina 與 Mandy 透過這個入口，確認新清單能使用正式設定與既有資料完成前面的操作。

正式環境的操作符合預期後，Brent 才在一般使用者的入口套用分流規則，將 GET /customers 交給新系統。切換後，團隊持續觀察新清單的請求與錯誤狀況。

如果新清單發生問題，Brent 可以恢復原本的分流規則，讓後續清單請求交回舊系統。這個安排成立，是因為舊清單仍可用，而且新清單沒有改變資料的寫入方式。

若後續連寫入功能或資料儲存都搬到新系統，就要重新確認切回條件。原本的程式是否能處理目前資料，不能只靠恢復分流規則判斷；還原程式與資料相容的關係，可以參考前面的資料與介面相容。

清理不再使用的舊功能

新清單持續符合需求後，團隊確認舊清單已不再使用，也不再需要切回，就可以移除舊清單專用的畫面程式與測試。但舊系統仍須提供新清單的資料查詢，以及新增與修改客戶的功能，因此還不能整個關閉。

後續替換其他功能時，也要先釐清它會讀寫哪些資料、呼叫哪些舊功能，以及切換時進行中的操作要如何處理。

等其他功能也完成替換，確認沒有請求、背景任務或資料存取仍依賴舊系統，也不再需要切回後，才能移除整個舊系統。過渡期間新增的讀取介面與轉接程式，也依是否仍有人使用來決定清理時機。

小結

系統替換可以持續一段時間，新程式仍能分步整合到主幹。這個案例透過讀取介面保留舊系統的資料處理，再由共同入口控制請求交給哪個系統，讓整合程式與切換功能分開安排。團隊可以持續維護共同版本，逐步移除不再使用的舊程式。

新舊系統分開執行後，團隊也可能需要同時調整多份程式。這些程式要放在同一個版本庫，還是分開管理，會影響共同修改與驗證的安排。

參考資料

• Martin Fowler：Strangler Fig
• Trunk Based Development：Application strangulation
• Microsoft：Strangler Fig pattern