舊系統的資料搬得過去嗎？ERP 資料轉移的真實成本

「資料轉移那一項，報價單上就一行字，我當時看了想說這應該很快吧。」

講這句話的老闆，導入走到第三個月卡住了。卡住的不是系統功能，是他舊系統裡那批「還沒結束」的單子——已出貨還沒開發票的、只交了一半的、客戶先付訂金的、掛在那邊兩年誰也不敢動的。這些單子要用什麼狀態進到新系統，會開了三次都沒有結論。而在那之前，他以為資料轉移就是舊的匯出、新的匯入，一個週末的事。

我是熊董，台灣川輝科技。我帶團隊做導入七年，經手 34 個案子、橫跨 12 個產業。所以這件事我想先把話講死：ERP 資料轉移是整份導入計畫裡最容易被低估的一項，而它被低估的原因，是大家把它想成一個「搬運」的動作，其實它是一連串「決策」。真正花時間的從來不是匯出匯入那個技術步驟，那部分通常幾天就跑完；花時間的是搬之前決定哪些資料要帶、帶進去之後要長成什麼樣子，以及搬完之後有沒有人肯花力氣去對、去驗、去簽名認帳。而且你要先接受一件很反直覺的事——有相當一部分的舊資料，正確的處理方式是不搬。搬了它不會讓你更安全，只會把舊系統裡的混亂原封不動複製一份到新系統，然後你換來一個長得比較新、但一樣不能信的資料庫。

先講清楚，這篇講的「成本」不是報價，是時間、是要多開幾次會、是上線那個月有多少人得留下來對數字。這三樣不會出現在任何一份報價單上，卻是資料轉移真正的代價。

先承認你是對的：資料當然要搬，但「搬」不是一個動作

你會擔心舊資料，這個直覺完全正確。客戶統編、聯絡人、送貨地址是十幾年累積的；料號跟規格是全公司溝通的共同語言；誰還欠著錢，是你判斷生意的依據。這些進不了新系統，等於把公司的記憶砍掉重來。所以「資料一定要能過去」是對的要求，我從來不勸客戶放棄。

錯的是把它想成一個動作。在老闆的想像裡，資料轉移是「工程師寫個程式，跑一個晚上，隔天早上資料就在新系統裡了」。這個畫面有一半是真的——程式確實會跑，而且跑得很快。但那個晚上之前，有一個月的工作沒有人看見，那一個月都在回答問題。

同一個客戶在舊系統裡有三筆資料，因為業務打過三種名稱，要合成一筆還是留三筆？合的話留哪一筆地址？舊系統的客戶等級有 A、B、C、VIP、老客戶五種值，新系統的分級邏輯不長這樣，怎麼對？舊料號裡混了規格，新系統要拆成編號加屬性，舊單據上那個編號怎麼辦？

每一題都不難，難的是有幾百題，而且只有你們公司的人答得出來，顧問答不了。所以資料轉移吃掉的不是工程師工時，是你跟你主管的決策時間。這一點在看報價時特別容易誤判，我在〈ERP 報價單怎麼看〉裡提過同樣的邏輯：字數最少的項目，往往佔用你自己人力最多。

三種資料，三種難度，不要混在一起談

「舊資料搬得過去嗎」沒辦法直接回答，因為「舊資料」至少是三種完全不同的東西。分開來看，你才評估得出這一項會不會爆。

第一種是主檔。 客戶、供應商、產品、料號、員工、倉別，這些是名詞，是新系統拿來組句子用的字。主檔技術難度最低，幾乎一定搬得過去；但清理難度最高，清不好會拖累後面所有事——主檔髒了，你搬過去的每一筆交易都掛在錯的名詞底下。所以主檔真正的工作不是轉移，是去重複、補空值、統一命名規則，而且沒有工具能全自動做，因為判斷「這兩筆是不是同一個客戶」需要人。

第二種是歷史交易。 過去的訂單、出貨單、進貨單、發票、收付款紀錄。特性是量大但單純——都已經結束了不會再變，新系統也不需要對它們做運算，查得到就好。難點不在技術，在你想搬多少、願意接受多粗的顆粒度。

第三種是未結案的單。 最麻煩也最常被忽略：已下單未出貨、已出貨未開票、已開票未收款、部分交貨、有預收或預付款、在製品、還沒盤完的庫存差異。它們的共同特徵是「還活著」——新系統接手後還要繼續對它們做動作，要能沖銷、能結案、能算帳齡。

它難在不只是資料，同時是一筆帳。一張只出了一半的訂單，進新系統時要顯示剩下多少未交？已交的那一半有沒有出貨紀錄？沒有的話，之後查這張單會看到一個斷掉的故事；有的話，你等於也搬了一部分歷史交易，而且要跟總帳對得起來。

我看過的導入案，上線日被往後推多半就是卡在這一類。功能測完了、教育訓練也上完了，就因為未結案單據的狀態對不起來，財務不敢簽字。

資料種類	技術難度	真正的工作	常見卡點
主檔（客戶、產品、料號）	低	去重複、統一命名、補齊必要欄位	沒有人有權決定「這兩筆是同一個嗎」
歷史交易（已結束的單）	中，量大	決定搬幾年、搬到多細	什麼都想搬，結果什麼都沒驗
未結案的單	高	逐張確認狀態，並與帳務對平	財務對不平就不敢上線，日期一路後推

「歷史資料要搬幾年」這個問題，其實問錯了

每個案子都會被問到這題，而且老闆問的時候通常心裡已有答案：「全部都要。」

我理解這個反應，全部搬聽起來最安全。但這個答案藏著一個沒被檢查的假設：你以為搬過去的資料就等於可用的資料。搬過去而沒被驗證過的歷史資料，你一樣不敢拿來做決策；而驗證要花人力，搬十年就要驗十年。多數公司驗到第二年就沒力氣了，剩下八年變成一堆躺在資料庫裡、誰也不會查、查了也不敢信的東西。

所以正確的問法不是「要搬幾年」，是這三題。

第一題：這批資料你打算拿來做什麼？ 答案通常是三種，而三種的搬法完全不同。如果是「客訴或保固時要查得到當初賣了什麼給誰」，你要的是單據層級的明細，但範圍大概只需涵蓋保固期加一點緩衝。如果是「想看趨勢、看客戶這幾年的消長」，你要的是按月按客戶按品項的彙總，不是每一張單的明細，資料量少一個級距，驗起來也快得多。如果是「怕以後查稅」，那答案往往根本不在新系統裡，下面會講。

第二題：不搬的話，查得到嗎？ 這題決定風險的真實大小。舊系統如果還能開、報表還印得出來，不搬的代價只是「查起來麻煩一點」，不是「查不到」，中間差很多。多數公司高估了這個風險，因為沒認真確認過舊系統能不能留著查。

第三題：搬進來之後，誰會去對？ 你說要搬五年，是誰要去確認這五年的數字對不對？沒有人有時間對的話，搬五年跟搬兩年的差別只是資料庫大小，沒有任何一年是可信的。

把這三題答完，「幾年」這個數字自己會浮出來，而且通常比老闆一開始講的少。我遇到的案子裡多半落在同一種分層做法：未結案的全部搬、近期交易搬明細、更早的搬彙總、再更早的留在舊系統或匯出封存。好處是把有限的驗證力氣，集中在真正會用到的那一段。

這個決定也會直接影響上線日，它是少數幾個「老闆一句話就能改變專案長度」的變數。整體時程怎麼估、哪些環節會互相牽動，我在〈ERP 導入要多久〉裡拆得比較細。

有些資料，正確答案是不搬

這一段大概是全文最不受歡迎的，但這才是省時間的地方。

已經不用的主檔不要搬。 五年沒下過單的客戶、早就停產的料號、離職三年的業務代號。搬進新系統換來的是每次下拉選單多滾三頁，更糟的是新人分不出哪些是活的，會挑到錯的。這些該做的是封存不是遷移——匯出一份放著，查得到就好。

錯誤的資料不要搬。 這句話像廢話，但現場很少人做得到。那些明知有問題的庫存差異、掛很久對不起來的應收餘額、當初為了讓報表好看而開的調整單，原封不動搬過去，新系統上線第一天帳就是錯的。而且從那天起，所有人都會說「那是舊資料的問題」，這句話會變成往後兩年掩蓋一切的萬用理由。寧可上線前用一次性的期初調整處理掉、留下說明，也不要讓錯誤混進新系統。

只為稅務或法規留的資料，不要放進系統，放進封存。 很多公司搬歷史資料的真實動機是怕以後查帳查稅。但這個需求要的是「拿得出來、看得懂、不能被竄改」，不是「在 ERP 裡查得到」。匯出成固定格式的檔案，附一份說明怎麼讀的文件，妥善保存就夠了。用 ERP 當保險箱，是又貴又難用的做法。

備註欄裡的暗號，要翻譯過再搬。 業助寫的「這家要先傳圖再出」、「這客戶星期三不收貨」，不是資料，是規則。直接複製到新系統的備註欄，只是換個地方繼續靠人記。該做的是挑出來，看哪些能變成欄位、標記或檢核。不做這件事，上線半年後大家還是在備註欄裡寫暗號。

真正吃時間的是驗證，不是匯入

把資料轉移的工作量畫成一條線，匯入只佔一小段。前面是清理與決策，後面是驗證與認帳，而後面這一段最常被整個跳過。

驗證不是「打開來看看有沒有東西」，是要對得起來：筆數、金額總數、隨機抽幾張單逐欄比對。前兩項機器算得出來，第三項一定要人做，而且要平常在用這批資料的人做，不是 IT 也不是顧問——只有他看得出「這欄數字雖然有進來，但意思跑掉了」。

比驗證更容易被跳過的是認帳。驗完之後要有人具名說「這批數字我認了，之後有問題不會再推給資料轉移」。沒有這個動作，新系統上線第一天就帶著一個免責條款，任何對不上的地方都能推給搬資料，你永遠查不出真因。一封信、一張確認單就夠，重點是有人簽名。

也因為驗證要人，排程不能壓在上線前一週。合理的做法是先演練：整批搬進測試環境，讓真正的使用者去查、去挑錯，再留時間修正。正式上線那次應該是第二次或第三次搬。我見過的失敗導入，不少就是敗在第一次搬就是正式搬，出問題只能一邊營運一邊救。

所以你明天該做什麼

不用等顧問，明天你自己就能做兩件事，做完你對這一項的風險判斷會完全不一樣。

第一件事，問你的財務或業助一句話：「我們現在有多少張單還沒結案？最舊的那張是什麼時候的？」如果對方要查很久，或者答完補一句「不過有幾張很奇怪」，你就找到這次導入最會拖時間的地方了。把那幾張奇怪的單挑出來，趁還沒開始導入先處理掉。

第二件事，打開舊系統的客戶主檔，用公司名稱排序，看有沒有長得很像的兩三筆；再看最後交易日期那一欄，數數看有多少筆三年以上沒動過。這兩個數字會告訴你，主檔清理要花的是一週還是一個月。

握著這兩個答案再去跟廠商談，對話品質會完全不同——你問的不再是「資料搬得過去嗎」，而是「這幾類我打算這樣處理，你們配合的方式是什麼」。這兩句話換來的時程估算，準確度差很遠。

如果你手上已有一份導入計畫，但看不出資料這段切得夠不夠細，可以找我聊三十分鐘，把三種資料的範圍先框出來。