分散流程

對應資料來源

如果我們要萃取並重新實作關鍵匯總器，我們首先需要了解它是如何連結到舊有資產的其餘部分。這表示分析並了解用於匯總的資料最終來源。在此處務必記住，我們需要取得最終的上游系統。例如，雖然我們可能會將大型主機視為銷售資訊的真實來源，但資料本身可能來自於商店的收銀機系統。

建立一個顯示匯總器以及上游和下游依賴關係的圖表至關重要。系統脈絡圖或類似圖表在此處可以發揮良好的作用；我們必須確保我們確實了解哪些資料從哪些系統流動，以及多久流動一次。舊有解決方案通常會成為資料瓶頸：來自（較新的）來源系統的額外有用資料通常會被捨棄，因為在舊系統中很難擷取或表示這些資料。有鑑於此，我們也需要擷取哪些上游來源資料被捨棄，以及在何處被捨棄。

使用者需求

顯然地，我們需要了解我們計畫「轉移」的功能是如何被最終使用者使用的。對於 關鍵匯總器，我們通常會為每個報表或指標擁有非常大量的使用者。這是 功能同等性 可能導致重建一組「過於龐大」的報表（實際上並未符合目前的使用者需求）的經典範例。一組簡化的較小報表和儀表板可能是更好的解決方案。

平行執行可能是必要的，以確保在初始實作期間關鍵數字相符，讓企業確信事情如預期般運作。

擷取產出產生方式

理想情況下，我們希望擷取目前的輸出是如何產生的。一種技術是使用順序圖來記錄舊系統中資料接收和處理的順序，甚至只是一個流程圖。然而，嘗試完全擷取現有實作通常會收益遞減，發現關鍵知識已遺失並非不尋常。在某些情況下，舊有程式碼可能是說明事物如何運作的唯一「文件」，而了解這一點可能會非常困難或昂貴。

一位作者與一位客戶合作，該客戶使用舊系統的匯出以及一個高度複雜的試算表來執行關鍵財務計算。組織中目前沒有人知道這是如何運作的，幸運的是，我們與一位最近退休的員工取得了聯繫。不幸的是，當我們與他們交談時，發現他們在十年前從前一位員工那裡繼承了這個試算表，而遺憾的是，這個人在幾年前已經過世了。對舊有報表和（兩次「版本移轉」）Excel 試算表進行反向工程，會比回到第一個原則並從頭定義計算應執行的動作更費工。

雖然我們可能不會在替換終端點中建立功能同等性，但我們仍需要關鍵輸出與舊系統「相符」。使用我們的彙總範例，我們現在可能能夠製作商店的每小時銷售報告，但企業領導人仍需要月底總計，而且這些總計需要與任何現有數字相關聯。我們需要與最終使用者合作，為給定的測試輸入建立預期輸出的實際範例，這對於稍後找出哪個系統（舊系統或新系統）是「正確的」至關重要。

交付與測試

我們發現，這種模式很適合採用迭代方法，我們可以分段建立新功能。對於關鍵彙總器，這表示輪流提供每份報告，並將它們一路帶到類似生產的環境中。然後，我們可以使用 平行執行 來監控已提供的報告，同時建立其餘報告，並讓測試使用者提供早期回饋。

我們的經驗是，許多舊有報告都包含未發現的問題和錯誤。這表示新輸出很少（如果有的話）與現有輸出相符。如果我們不完全了解舊有實作，通常很難了解不符的原因。一種緩解措施是使用自動化測試，在實作階段注入已知資料並驗證輸出。理想情況下，我們會對新舊實作都這麼做，這樣我們就能針對同一組已知輸入比較輸出。然而，在實務上，由於舊有測試環境的可用性以及注入資料的複雜性，我們通常只對新系統這麼做，這是我們建議的最低限度。

在舊有彙總中找到「系統外」的解決方法很常見，顯然在移轉作業期間，試著追蹤這些解決方法很重要。最常見的範例是，領導團隊所需的報告實際上無法從舊有實作中取得，因此有人手動調整報告，以建立他們實際看到的輸出 - 這通常需要好幾天。由於沒有人想要告訴領導階層報告實際上無法運作，因此他們通常不知道事情的實際運作方式。

上線

一旦我們對新彙總器中的功能感到滿意，我們就可以將使用者轉移到新解決方案，這可以用分階段的方式進行。這可能表示為主要使用者群體實作報告、一段平行執行期間，最後才使用新報告完全切換到他們身上。

監控與警示

在轉移流程中，正確的自動化監控和警示至關重要，特別是在依賴關係仍存在於舊有系統中的時候。您需要監控更新是否如預期收到、是否在已知的良好範圍內，以及最終結果是否在容許範圍內。手動執行此檢查很快就會變成很多工作，而且可能會造成錯誤來源和延誤。一般來說，我們建議修復在上游系統中發現的任何資料問題，因為我們想要避免將過去的解決方法重新引入到新解決方案中。作為額外的安全措施，我們可以讓平行執行持續一段時間，並選擇性地使用調和工具，如果舊實作和新實作開始出現過大差異，就會產生警示。