在新系統替換老系統或者系統升級的項目中，難免會存在數據遷移的工作，并且隨著業務系統和數據結構的復雜性，數據遷移的難度越大。

這亦要求在項目實施的前期，根據客戶的需求盡可能全面地考慮到各個方面，輸出一份詳細的數據遷移方案。

筆者將結合實際的項目工作經驗，將一些在數據遷移中的感悟與各位分享共勉。

一、遷移準備

遷移前需要調研的內容包含：

1. 老系統存儲數據所使用的數據庫類型

例如oracle、mysql、sqlserver等，或某些廠商封裝的數據庫，因為每種數據庫的數據存儲結構形式存在差異，新老系統如果使用不同的數據庫，難免需要處理。對于常見的數據庫轉換，市面上有開源工具可批量處理。

2. 老系統存儲數據的形式

是否包含圖片、表單、音視頻等多媒體內容；是否包含附件，附件是否可在線預覽；系統內的數據是否有相互關聯關系等。這些將作為遷移完成后，驗證遷移效果的重要用例。

3. 老系統的業務分類

無論是CRM系統、OA系統、工單系統，都會細分具體的業務類型，數據遷移的時候，必然需要按照其對應的業務分類遷移，因此需要調研其詳細的業務分類。

二、遷移內容

遷移的內容主要是需要根據客戶的需求，來確定數據的哪些內容是需要遷移的，將其總結為如下幾個方面：

1. 數據字段對應

根據調研，輸出一個數據字典對照表，新系統和老系統存儲數據的每個字段會不一樣，但實際上對于業務來說，功能用處是一樣的；另外，如果老系統含有特有字段，而新系統沒有，那么就需要在新系統開發對應的數據表進行存儲。

下表是項目中一個KM系統的數據字典對照表：

2. 數據的關聯關系

數據庫里數據之間的相互關聯，和其他外部系統數據的相互關聯，這部分內容在遷移的時候，需要有相互關聯的關系表，一般是以數據ID之間的關聯關系來識別，因為ID是每條數據的唯一標識。

3. 其他附件數據

這部分內容可能是掛在某條數據下面，也就和數據之間進行了關聯，亦需要關聯關系表，同樣以ID來識別。

另外，也可能是單獨上傳的附件，這部分可直接獲取。附件會存儲在文件服務器上，且業務系統一般會在內網部署，遷移時，可直接讀取附件URL地址進行下載上傳。需要注意的是，在URL鏈接里需要拼接附件名字，不然只有附件的ID。

三、遷移方式

數據如何從一個系統遷移到另一個系統？

目前所接觸有兩種方式：

• 一是離線的方式，導出本地文件，再導入；
• 另一種是在線的方式，通過接口調用傳參實現。

由于涉及到兩個系統，意味著有第三方（而且往往是新系統的廠商要去替換老系統的廠商，也就是搶別人的飯碗），其第三方配合程度是不可控因素，兩種遷移也就各有優缺點。

1. 離線方式

需客戶協調老系統導出本地數據（可寫SQL語句導出，也可寫代碼導出，根據業務內容決定），在導出之前，應根據遷移內容提供標準的數據模板，包括數據字典模板、關聯關系模板、業務分類模板等。

優點：所有數據已導出，均在自己手中，實施遷移的時候，很多問題都在自己的可控范圍。

缺點：

1. 數據量過大時，導入導出時間長，且可能存在程序崩潰的風險（可考慮分批次）；
2. 在新老系統過度期間，需要多次執行導出導入。

2. 在線方式

接口傳參需要第三方開發調用接口，同樣在開發接口之前，需按照遷移內容提供標準的統一接口文檔。同時，為不影響生產系統，也可能需過濾一些敏感信息，需建立中間庫。

優點：在系統切換過度期間，可定時掃描調用接口傳參（即增量數據）。

缺點：需要第三方開發，有工作量，且調試接口的時候，配合程度不可控。

四、實施遷移

實施遷移即數據整理與數據轉換。數據整理就是將老系統數據整理為系統轉換程序能夠識別的數據；數據轉換就是將整理完成后的數據按照一定的轉換規則轉換成新系統要求的數據格式。

同時這部分需要開發遷移代碼，在代碼完成后，特別注意的是需先進行小批量的遷移進行驗證，無問題后，再進行大批量直至全量遷移。

五、遷移保障

為保障遷移的整個過程順利和遷移數據完整準確性，過程中需要有如下幾個方面可參考：

1. 遷移的數據全量備份：防止系統崩潰，數據丟失；
2. 遷移過程打印日志：（如：遷移了多少數據，其中成功多少條，失敗多少條）；
3. 遷移完的驗證：a.如在遷移準備中第2點描述的數據的集中類型，需核對是否與老知識庫對應，展現形式是否完整；b.抽檢數據驗證，可按照GB2828-81中的AQL值為標準進行抽檢，抽檢的方式可按照分層抽樣（即每多少條數據抽檢幾條驗證）。

結語

以上為個人在項目中關于數據遷移的一些感悟總結，最后將整個數據遷移的過程以一張圖總結下：

作者：菜鳥店小二，AI產品經理

本文由 @菜鳥店小二 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。