遺留系統需要保留哪些資料？

前一章已經建立與正式環境隔離的重構環境，讓開發人員可以在不影響現行運作的情況下分析資料。接下來需要確認遺留系統保存了哪些資料、這些資料目前有甚麼用途，以及目標系統是否仍然需要它們。

直接搬走所有內容，可能把重複、錯誤或已失去用途的資料一併帶入目標系統，也會擴大敏感資料的保存範圍。只按照資料的建立時間或檔案名稱刪除，則可能破壞功能、歷史查詢或必要的保存責任。每一項資料都需要有明確用途、處理方式與確認結果。

本章要將資料分成四種處理方式：

1. 遷移至目標系統，繼續支援保留或調整後的功能。
2. 移出日常處理範圍並封存，在保存期限內保留完整內容。
3. 保留查詢方式，讓相關人員可以查閱，但不再由目標系統修改。
4. 在確認沒有用途與保存責任後刪除。

這項分類會成為後續資料模型設計、資料轉換、遷移驗證與既有系統退場的共同依據。

從資料用途決定保留範圍

資料的保存位置與格式無法單獨說明它的重要性。同一份資料可能散落在保存狀態、檔案、輸出結果與外部相依項目中；名稱相近的內容也可能代表不同時間點或不同規則。確認範圍時，應該從已經列出的功能與資料流向反向追查：

1. 列出每項保留或調整後的功能會讀取、建立及修改哪些資料。
2. 確認輸出結果、後續處理與外部相依項目會使用哪些內容。
3. 找出自動執行工作需要的初始資料、執行狀態與處理紀錄。
4. 比較內容相同或相近的資料來源，確認哪一處是主要來源，哪些只是副本或暫存內容。
5. 記錄資料涵蓋的時間範圍、更新方式，以及停止更新後是否仍有查詢或保存用途。

可以從先前整理出的功能規格、資料流向、保存狀態與相依關係開始，再使用程式碼、實際資料、執行紀錄及現有文件交叉確認。檔名、欄位名稱或註解只能作為線索。如果實際內容與名稱不一致，應該記錄差異並找出能確認資料用途的人員。

如果相同內容存在多份副本，需要分別記錄主要來源、產生方式與使用對象。可以從其他資料重新產生的內容，未必需要遷移。無法重新產生但仍有用途的結果，則需要納入保存範圍。

找出不同類型的資料

先按照用途分類，可以降低只檢查單一保存方式而遺漏資料的風險。實際系統不一定具備下列所有類型，應該按照已確認的功能與組成項目選用。

如果系統具備身分識別或存取限制，相關識別資料、角色對應與驗證資訊也需要另行列出。這些內容的處理方式與一般功能資料不同，不能因為目標系統需要登入功能，就直接複製所有既有驗證資訊。

同時保留資料的含義與關係

只有資料內容，未必足以讓目標系統正確解讀。例如，數字 1 可能代表啟用狀態、分類代碼或處理順序；日期可能使用不同時區或只記錄到日期；空白值也可能分別代表未知、不適用或尚未處理。這些差異如果沒有記錄，後續轉換時就容易把有效資料改成錯誤結果。

每一類準備保留的資料，至少需要補充下列資訊：

• 說明每個欄位或內容片段代表的意思、格式、單位與允許值。
• 記錄代碼、分類與狀態值的對照方式，以及規則生效的時間範圍。
• 說明資料之間使用哪些識別內容建立關係，缺少關聯時如何判斷。
• 區分原始輸入、系統計算結果、人工修正內容與可以重新產生的衍生資料。
• 記錄時間、文字編碼、空值與特殊字元的實際表示方式。
• 保存產生重要結果所需的規則版本、設定內容與來源資訊。

這些資訊可以整理成資料字典、代碼對照表與關係說明。它們不一定會成為目標系統直接處理的資料，卻是設計目標資料結構、撰寫轉換規則及驗證遷移結果的必要依據。

區分遷移、封存、保留查詢與刪除

四種處理方式代表不同目的與後續責任，不能只用「保留」概括。判斷時需要同時考慮功能用途、相依關係、保存要求、資料品質與敏感程度。

同一類資料可以按照時間或狀態採用不同方式。例如，近期內容由目標系統繼續處理，較早內容只提供查詢，更早且仍有保存責任的內容則封存。切分條件需要寫成可以執行與驗證的規則，避免只使用「近期」或「重要資料」等無法判斷的描述。

資料品質問題也不會自動決定資料去留。仍被功能或規範要求使用的錯誤資料，需要先記錄問題與核准的處理方式；沒有用途的完整資料，也不需要只因內容齊全就遷移。無法立即確認的資料可以暫列為待決定，但必須記錄確認人員與完成期限。

個別處理敏感資料與驗證資訊

個人資料、機密內容及其他敏感資訊會提高複製、保存與查閱的風險。列出這些資料時，只記錄類型、位置、用途與保護需求，不要把實際內容貼入清單、文件或執行紀錄。

如果系統保存密碼、權杖（Token）、憑證（Credential）或私密金鑰（Private Key），這些資訊不能視為一般設定直接搬移：

• 確認程式、設定、執行紀錄、匯出內容與備份中是否存在可直接使用的敏感資訊。
• 目標系統需要的驗證資訊應該按照新的保存與驗證方式處理；無法安全沿用時，採用重新設定、重新簽發或更換方式。
• 既有系統仍在運作期間，不要因為準備目標系統而提前停用現行功能所需的資訊。
• 正式切換並確認不再需要後，按照核准程序停用既有資訊，並清除遷移過程產生的暫存副本。

如果保存內容包含敏感資訊，保存位置需要符合組織核准的用途與保護要求，並且視實際風險採用加密、存取限制、查閱紀錄及期限管理。內部或敏感內容不應該放在私人儲存空間。為分析或測試建立的副本，也需要移除不必要的敏感內容，並在用途結束後按照既定期限清除。

保存期限與處理方式需要符合適用規範、契約與組織要求。無法確認時，先交由負責該資料或規範的人員判斷，不要自行設定期限或直接刪除。

建立可以執行的資料保留清單

資料保留清單需要讓後續人員知道要處理哪些內容、為甚麼這樣處理，以及如何確認結果。每一列代表一個能採用相同決策與期限的資料範圍；同一來源內需要不同處理方式的內容，應該拆成不同項目。

「資料負責人」是能確認資料含義與使用責任的人員，不代表由一個人完成所有技術處理。「核准人員」則需要有權決定保留期限與刪除方式；兩者可能是不同角色。責任不清楚時，先記錄目前能確認的來源與待決定事項，避免讓暫時推測成為正式決策。

驗證保存與刪除結果

清單完成後，還需要確認每項決策可以實際執行。可以選取具代表性的內容進行取回與解讀，確認保存的資料、結構說明與關係資訊足以回答原本的查詢需求。只留下無法開啟的格式、缺少對照內容的代碼，或需要依靠特定人員記憶才能解讀，都不算完成保存。

刪除前應該重新檢查功能、外部相依、歷史查詢與保存要求，並取得核准。刪除範圍也要包含為分析、測試、轉換或傳遞而建立的副本與暫存內容。執行後記錄處理時間、範圍、結果與例外項目，讓既有系統退場時可以確認沒有遺留不受管理的資料。

完成本章工作後，資料保留清單應該能回答下列問題：

• 每一項資料目前由哪些功能、輸出或外部相依使用？
• 需要保留哪些時間範圍、資料關係與解讀資訊？
• 哪些內容包含敏感資訊，後續需要採用甚麼保護方式？
• 每一項資料要遷移、封存、保留查詢或刪除，理由是甚麼？
• 誰確認資料用途，誰核准保存期限與刪除決策？
• 要用甚麼條件驗證保存、查詢或刪除結果？

如果其中一項仍無法回答，就將它保留在待確認清單，不要直接進入刪除或正式遷移。後續章節會使用已核准的遷移範圍與資料解讀資訊，建立來源與目標之間的對應、轉換及驗證方式。

重點整理

• 資料保留決策需要從功能、輸出、外部相依與保存責任確認用途，不能只按照保存位置、名稱或建立時間判斷。
• 功能資料、參照資料、歷史紀錄、稽核紀錄、檔案與系統設定都可能需要處理，實際範圍應該按照系統構成確認。
• 保存資料時需要一併記錄欄位含義、代碼對照、資料關係、時間格式與規則版本，確保後續仍能正確解讀。
• 遷移、封存、保留查詢與刪除具有不同目的，必須分別記錄適用範圍、期限、驗證條件與核准結果。
• 個人資料、機密內容與驗證資訊需要個別確認保護及更換方式，不應該把實際敏感內容寫入清單或一般文件。
• 資料保留清單應該記錄用途、來源、負責人、敏感程度、處理決策、保存期限與驗證條件，作為後續資料遷移與既有系統退場的依據。