換系統時的資料轉移：盤點清洗、對應規則、試轉驗證與切換安排
換系統的評估階段，大家討論的多半是功能夠不夠、介面好不好用、價格怎麼算。等到真的要換了才會發現，整個專案最容易出事的其實是另一件事：舊資料怎麼搬過去。
客戶名單搬完後少了一批、訂單金額和舊系統對不起來、同一位客人變成三筆資料——這些狀況一旦發生在切換之後，處理起來相當耗神，而且會直接影響同仁對新系統的信心。以下把資料轉移拆成四個階段——盤點與清洗、對應規則、試轉與驗證、切換安排——說明每一段該做什麼、業主端要負責什麼。
換系統的風險，大半落在資料這一段
新系統的功能是可以測試的：按鈕會不會動、流程跑不跑得通，測一次就知道。但資料不同，資料的正確與否往往要等實際使用時才被發現，而且發現的人通常是客戶或第一線同仁。
原因在於資料的問題多半不是「搬不過去」，而是「搬過去但意思變了」。舊系統的某個欄位叫做「備註」，裡面其實混雜了客戶的特殊需求、業務的提醒、以及早年某次活動的紀錄；新系統把它原封不動搬進一個叫「備註」的欄位，技術上完全成功，實際上這些資訊仍然沒人看得懂、也沒辦法查詢。
所以資料轉移不是一個技術動作，而是一次盤點與決策的過程。技術執行由廠商負責，但「什麼是對的資料」只有業主端能回答。認清這點，時程與人力才會抓得準。如果你正在評估的是要修、要換還是重寫，可以先看舊系統現代化指南再決定要不要進到資料這一關。
第一階段：資料盤點與清洗
盤點的目的是把「系統裡有哪些資料」攤開來看。要回答的問題包括：
- 有哪幾類資料（客戶、訂單、商品、庫存、發票、交易紀錄、附件檔案）。
- 每一類大約有多少筆、最早可以追溯到什麼時候。
- 這些資料現在存在哪裡——主系統、試算表、共用資料夾、還是某位同事的電腦。
- 每一類資料由誰負責、誰最清楚它的規則。
最容易被漏掉的是系統外的資料。很多公司的關鍵資訊其實放在試算表裡：業務自己維護的客戶分級、會計的對帳表、倉管的進出紀錄。這些東西不在舊系統裡，盤點時如果沒問，切換之後才發現要另外處理。
盤點也要一併確認附件檔案：合約掃描檔、商品圖片、客戶上傳的文件。這些檔案通常數量大、存放方式雜亂，而且與資料筆數的關聯要另外對應，工作量常被低估。
盤完之後接著清洗。舊系統跑了幾年，資料一定會累積問題，常見的有五類：
- 重複：同一位客戶因為手機號碼打錯或名字有空格，變成多筆。
- 缺漏：早期沒有強制填寫的欄位，前面幾年的資料是空的。
- 格式不一致：電話有的加區碼有的沒有、日期有的用民國有的用西元、地址寫法五花八門。
- 不合理的值：測試資料忘了刪、金額是負數、日期在未來。
- 語意漂移：同一個欄位在不同時期被拿來存不同的東西。
清洗的關鍵不在技術，而在誰來決定規則。同一位客戶有三筆資料，要合併成哪一筆、保留誰的地址，這是業務判斷。有效的分工是廠商負責掃出問題清單，業主端指派熟悉業務的同事訂出處理規則，廠商再批次執行。
最常踩到的一步是把清洗排在轉移之後，想著「先搬過去再慢慢整理」。實務上這幾乎不會發生——新系統上線後大家忙著適應，沒人有空回頭整理，結果舊系統的問題就永久留在新系統裡了。
歷史資料要不要全部搬
這是最常被問、也最常做錯決定的一題，而且要在盤點階段就決定，因為它直接決定後面三個階段的工作量。預設答案不是「全部搬」，而是「依用途決定」。
把資料分成三類來看：
- 必須搬：日常營運會用到的、法規或稅務要求保存的、客戶會查詢的。
- 可以搬：偶爾查詢的歷史紀錄，搬過去有好處但不搬也能運作。
- 不必搬：多年沒人看過的資料、已失效的測試資料、與新業務模式無關的舊紀錄。
第一類裡的「法規或稅務要求保存」要特別確認：**保存年限依稅務規定與所屬產業的法規而定，各行業不一樣，決定之前先向你的會計或主管機關確認，不要憑舊系統的預設值或前一任承辦的習慣推斷。**會計憑證、帳簿、出勤紀錄與工資清冊這幾類常見單據的法定年限與法條，整理在電子表單與簽核流程系統的「保存期限」段。
第三類的處理方式通常是匯出成檔案存查，或讓舊系統保留一段時間作為唯讀查詢用。這兩種都比硬搬進新系統划算——搬進去不只增加轉移工作量，也會讓新系統的資料品質從第一天就打折。
判斷方法：問負責的同仁一句話，「過去一年你查過多久以前的資料？」答案通常比想像中近。真正需要長期保存的，往往是法規要求而非日常使用，那些用存查方式處理就夠了。會員與交易資料的搬遷邏輯，在會員系統與 CRM 開發指南裡也有相關討論。
第二階段：對應規則，舊欄位怎麼變成新欄位
這一步是把舊系統的每一個欄位，明確對應到新系統的某個位置，並寫下轉換規則。實務上大致有四種情況：
一對一直接搬：舊的客戶姓名對應新的客戶姓名，最單純。
需要轉換：舊系統用代號 1、2、3 代表訂單狀態，新系統用文字；或舊系統的地址是一整串文字，新系統拆成縣市、區、路名三欄。這類要寫清楚轉換邏輯，包括對不上的值怎麼處理。
需要拆分或合併：一個「備註」欄要拆成幾個有意義的欄位，或幾個舊欄位合併成一個。這類通常需要人工判斷，數量大的話要評估是否值得。
新系統沒有的、或新系統多出來的：舊系統有但新系統不需要的欄位，決定是捨棄還是存成備查；新系統需要但舊系統沒有的，決定給預設值還是留空。
這份對應表要留下來，它是日後查證「這筆資料為什麼長這樣」的唯一依據。轉移完成幾個月後有人質疑數字對不上，沒有對應表就只能靠記憶。
如果搬的是會員或客戶資料，還要一併確認個資的處理方式與保存範圍，網站隱私權政策怎麼寫裡有基本原則可以對照。
第三階段：試轉與驗證，怎麼確認搬對了
試轉就是在正式切換之前，先用真實資料完整跑一次轉移，把結果放進測試環境檢查。這一步不能省，而且通常要跑不只一次——第一次找出問題、修正規則、再跑第二次確認。
驗證有三個層次，建議都做：
第一，總量核對。舊系統有多少筆客戶、多少筆訂單，新系統轉完之後數字對不對。數量對不上最容易發現，也最該優先處理。
第二，金額與統計核對。挑幾個關鍵數字比對，例如某個月份的訂單總額、某位客戶的累計消費、目前的庫存總數。這類驗證能抓出「筆數對但內容錯」的問題。
第三，逐筆抽查。由熟悉業務的同事挑選幾十筆有代表性的資料實際比對，包括最新的、最舊的、金額最大的、狀態特殊的、以及已知有問題的那幾筆。這一步最花時間，但也最能抓到自動比對看不出來的語意錯誤。
驗證要由業主端執行，不能只看廠商的報告。廠商能確認程式有沒有照規則跑，但規則本身對不對，只有懂業務的人看得出來。這一段的安排方式與功能驗收相同：由實際會使用這些資料的人負責判斷對錯，並留下書面的比對紀錄。
第四階段：切換日怎麼安排
切換是整件事風險最集中的一天，值得事先寫成一張時間表，每個步驟標註負責人與預計耗時。一般的順序是這樣：
- 公告停機時間，通知所有會受影響的同仁與必要的客戶。
- 舊系統停止新增資料（進入唯讀狀態）。
- 完整備份舊系統，並確認備份檔案可以還原。
- 執行正式轉移。
- 依既定清單驗證（總量、金額、抽查）。
- 確認無誤後開放新系統，舊系統維持唯讀。
時間點的選擇要避開業務高峰與結帳期間，通常安排在週末或連假。但要留意：假日如果出問題，廠商與內部同仁是否找得到人，這要事先講好。
事先訂出退回標準是最常被忽略的一項。什麼情況下決定放棄切換、退回舊系統？誰有權做這個決定？時限是幾點以前？沒有事先訂好，當天出狀況時大家會在壓力下猶豫，反而拖到更難收拾。
如果系統涉及對外的網址結構變動，還要一併處理搜尋引擎的搬遷細節，這部分可以看網站改版 SEO 檢查清單。
切換後的觀察期與退路
切換完成不等於結束。上線後的頭幾週要安排觀察期，重點放在三件事：
第一，安排容易發現問題的機制。明確告訴同仁「發現資料怪怪的請回報到這裡」，並指定一位彙整的人。第一線同仁通常是最早察覺異常的人，但如果沒有明確管道，他們會傾向自己默默手動修正。
第二，保留舊系統一段時間。維持唯讀可查詢，讓大家在懷疑時能回頭核對。保留多久要事先決定並公告，避免變成永久並行——兩套系統長期並存會產生新的資料不一致問題。
第三，安排一次回顧。上線一個月後檢視發現過哪些資料問題、哪些是轉移造成的、哪些其實舊系統本來就有。這份紀錄對日後任何一次系統異動都有價值。
資料轉移做得好的專案，共同點通常不是技術多高明，而是準備期願意花時間盤點與清洗，而且業主端真的派了懂業務的人參與驗證。這部分的投入無法外包，也是換系統能不能順利落地的關鍵。
換系統的報價通常取決於資料這一段有多亂，而不是新系統有幾個功能。想先知道你手上的資料會落在哪個難度，把現況拿給 NETVANA 看看：我們會先盤點既有資料的狀況與使用需求，再談轉移方式與時程。軟體服務沒有固定套餐，一律先了解需求再報價，各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：如果換的是對外網站，整體流程可以看網站改版怎麼進行；驗證資料與驗收功能的方法相通，看軟體驗收怎麼做；要換的是內部使用的系統，可以讀內部後台系統開發指南；切換當天的流程安排可以參考網站上線前檢查清單。
