遷移遺留數據而不搞砸

遷移遺留數據很困難。

許多組織擁有陳舊而復雜的本地業務 CRM 系統。 今天，有很多雲 SaaS 替代方案，它們帶來了很多好處； 隨用隨付，只為您使用的東西付費。 因此，他們決定遷移到新系統。

沒有人願意將有關客戶的寶貴數據留在舊系統中並從空的新系統開始，因此我們需要遷移這些數據。 不幸的是，數據遷移並非易事，因為數據遷移活動消耗了大約 50% 的部署工作。 據 Gartner 稱，Salesforce 是雲 CRM 解決方案的領導者。 因此，數據遷移是 Salesforce 部署的一個主要話題。

那麼，我們如何確保將遺留數據成功轉換為閃亮的新系統，並確保我們將保留其所有歷史記錄？ 在本文中，我提供了成功進行數據遷移的 10 個技巧。 前五個技巧適用於任何數據遷移，無論使用何種技術。

一般數據遷移

1. 使遷移成為一個單獨的項目

在軟件部署清單中，數據遷移不是由智能的“一鍵式”數據遷移工具處理的“導出和導入”項目，該工具具有針對目標系統的預定義映射。

數據遷移是一項複雜的活動，需要單獨的項目、計劃、方法、預算和團隊。 必須在項目開始時創建實體級別的範圍和計劃，以確保不會出現意外，例如“哦，我們忘記加載那些客戶的訪問報告，誰來做？” 截止日期前兩週。

數據遷移方法定義了我們是一次性加載數據（也稱為大爆炸），還是每週加載小批量數據。

不過，這不是一個容易的決定。 必須就該方法達成一致並與所有業務和技術利益相關者進行溝通，以便每個人都知道何時以及哪些數據將出現在新系統中。 這也適用於系統中斷。

2. 實際估計

不要低估數據遷移的複雜性。 這個過程伴隨著許多耗時的任務，這在項目開始時可能是不可見的。

例如，為訓練目的加載特定數據集，其中包含大量真實數據，但敏感項目被混淆，因此訓練活動不會向客戶生成電子郵件通知。

估計的基本因素是要從源系統傳輸到目標系統的字段數。

每個字段在項目的不同階段都需要一些時間，包括了解字段、將源字段映射到目標字段、配置或構建轉換、執行測試、測量字段的數據質量等。

使用智能工具，例如 Jitterbit、Informatica Cloud Data Wizard、Starfish ETL、Midas 等，可以減少此時間，尤其是在構建階段。

特別是，了解源數據——任何遷移項目中最關鍵的任務——不能通過工具自動化，而是需要分析師花時間逐個瀏覽字段列表。

對整體工作量的最簡單估計是從遺留系統轉移的每個領域需要一個人日。

一個例外是相同源模式和目標模式之間的數據複製，無需進一步轉換——有時稱為 1:1 遷移——我們可以根據要復制的表的數量來估計。

詳細的估算本身就是一門藝術。

3.檢查數據質量

即使遺留系統沒有報告數據質量問題，也不要高估源數據的質量。

新系統有新規則，舊數據可能會違反這些規則。 這是一個簡單的例子。 在新系統中，聯繫電子郵件可能是強制性的，但 20 年曆史的舊系統可能有不同的觀點。

可能有隱藏在歷史數據中的地雷，這些地雷很長時間沒有被觸及，但在轉移到新系統時可能會激活。 例如，使用不再存在的歐洲貨幣的舊數據需要轉換為歐元，否則必須將貨幣添加到新系統中。

數據質量顯著影響工作量，簡單的規則是：我們走得越遠，我們就會發現更大的混亂。 因此，儘早決定我們希望將多少歷史轉移到新系統中至關重要。

4. 吸引商務人士

業務人員是唯一真正了解數據的人，因此他們可以決定哪些數據可以丟棄，哪些數據可以保留。

在映射練習中讓業務團隊中的某個人參與非常重要，對於未來的回溯，記錄映射決策及其原因很有用。

既然一張圖值一千多字，那就在新系統中加載一個測試批次，讓業務團隊來玩。

即使數據遷移映射得到業務團隊的審核和批准，一旦數據顯示在新系統的 UI 中，也會出現意外。

“哦，現在我明白了，我們必須稍微改變一下，”成為常用短語。

未能聘請通常非常忙碌的主題專家是新系統上線後出現問題的最常見原因。

5.瞄準自動化遷移解決方案

數據遷移通常被視為一次性活動，開發人員最終往往會得到充滿手動操作的解決方案，希望只執行一次。 但是有很多理由可以避免這種方法。

• 如果遷移分為多個波，我們必須多次重複相同的操作。
• 通常，每一波至少有 3 次遷移運行：用於測試數據遷移性能和功能的試運行，用於測試整個數據集和執行業務測試的完整數據驗證負載，當然還有生產負載。 運行次數隨著數據質量差而增加。 提高數據質量是一個迭代過程，因此我們需要多次迭代才能達到預期的成功率。

因此，即使遷移本質上是一次性活動，手動操作也會顯著減慢您的操作。

Salesforce 數據遷移

接下來，我們將介紹成功遷移 Salesforce 的五個技巧。 請記住，這些技巧也可能適用於其他雲解決方案。

6. 為長時間的負載做準備

從內部部署遷移到雲解決方案時，性能是（如果不是最大的話）權衡之一——不排除 Salesforce。

本地系統通常允許將數據直接加載到底層數據庫中，並且借助良好的硬件，我們可以輕鬆地達到每小時數百萬條記錄。

但是，不在雲端。 在雲中，我們受到幾個因素的嚴重限制。

• 網絡延遲——數據通過互聯網傳輸。
• Salesforce 應用層——數據通過厚厚的 API 多租戶層移動，直到它們進入 Oracle 數據庫。
• Salesforce 中的自定義代碼——自定義驗證、觸發器、工作流、重複檢測規則等——其中許多禁用並行或批量加載。

因此，負載性能可能是每小時數千個帳戶。

它可以更少，也可以更多，具體取決於字段、驗證和触發器的數量。 但它比直接加載數據庫要慢幾個等級。

還必須考慮性能下降，這取決於 Salesforce 中的數據量。

它是由用於檢查外鍵、唯一字段和重複規則評估的底層 RDBMS (Oracle) 中的索引引起的。 基本公式是每 10 級減速大約 50%，這是由 O(logN) 排序和 B 樹操作中的時間複雜度部分引起的。

此外，Salesforce 有許多資源使用限制。

其中之一是將批量 API 限制設置為 24 小時滾動窗口中的 5,000 個批次，每批次最多 10,000 條記錄。

因此，理論上的最大值是 24 小時內加載 5000 萬條記錄。

在實際項目中，由於使用自定義觸發器等有限的批處理大小，最大值要低得多。

這對數據遷移方法有很大的影響。

即使對於中等規模的數據集（從 100,000 到 100 萬個賬戶），大爆炸方法也是不可能的，因此我們必須將數據拆分為更小的遷移波。

當然，這會影響整個部署過程並增加遷移的複雜性，因為我們會將數據增量添加到已經由先前遷移和用戶輸入的數據填充的系統中。

我們還必須在遷移轉換和驗證中考慮這些現有數據。

此外，冗長的負載可能意味著我們無法在系統中斷期間執行遷移。

如果所有用戶都位於一個國家/地區，我們可以利用夜間 8 小時的中斷。

但對於像可口可樂這樣業務遍布全球的公司來說，這是不可能的。 一旦我們在系統中有美國、日本和歐洲，我們就會跨越所有時區，所以星期六是唯一不影響用戶的中斷選項。

這可能還不夠，因此，我們必須在用戶使用系統時在線加載。

7. 在應用程序開發中尊重遷移需求

應用程序組件，例如驗證和触發器，應該能夠處理數據遷移活動。 如果系統必須在線，則不能在遷移加載時硬禁用驗證。 相反，我們必須在驗證數據遷移用戶執行的更改時實現不同的邏輯。

• 不應將日期字段與實際系統日期進行比較，因為這會禁用歷史數據的加載。 例如，驗證必須允許輸入遷移數據的過去帳戶開始日期。
• 強製字段，可能不會填充歷史數據，必須作為非強制實施，但驗證對用戶敏感，因此允許來自遷移的數據為空值，但拒絕來自普通用戶通過 GUI 提供的空值.
• 觸發器，尤其是那些向集成發送新記錄的觸發器，必須能夠為數據遷移用戶打開/關閉，以防止遷移數據淹沒集成。

另一個技巧是在每個遷移對像中使用字段 Legacy ID 或 Migration ID。 有兩個原因。 第一個很明顯：保留舊系統的ID以進行回溯； 在數據進入新系統後，人們可能仍希望使用舊 ID 搜索他們的帳戶，這些舊 ID 可以在電子郵件、文檔和錯誤跟踪系統等地方找到。 壞習慣？ 可能是。 但是，如果您保留他們的舊 ID，用戶會感謝您。 第二個原因是技術性的，因為 Salesforce 不接受為新記錄明確提供的 ID（與 Microsoft Dynamics 不同），而是在加載期間生成它們。 當我們想要加載子對象時會出現問題，因為我們必須為它們分配父對象的 ID。 由於我們只有在加載後才能知道這些 ID，所以這是徒勞的。

讓我們使用 Accounts 和他們的 Contacts，例如：

1. 為帳戶生成數據。
2. 將客戶加載到 Salesforce，並接收生成的 ID。
3. 在聯繫人數據中加入新的帳戶 ID。
4. 為聯繫人生成數據。
5. 在 Salesforce 中加載聯繫人。

我們可以通過加載具有存儲在特殊外部字段中的 Legacy ID 的帳戶來更簡單地做到這一點。 該字段可以用作父級引用，因此在加載聯繫人時，我們只需使用 Account Legacy ID 作為指向父級 Account 的指針：

1. 為客戶生成數據，包括舊版 ID。
2. 為聯繫人生成數據，包括 Account Legacy ID。
3. 將客戶加載到 Salesforce。
4. 在 Salesforce 中加載聯繫人，使用 Account Legacy ID 作為父參考。

這裡的好處是我們將生成階段和加載階段分開，這允許更好的並行性，減少中斷時間等等。

8. 了解 Salesforce 的特定功能

與任何系統一樣，Salesforce 有很多我們應該注意的棘手部分，以避免在數據遷移過程中出現令人不快的意外。 這裡有幾個例子：

• 對活動用戶的一些更改會自動為用戶電子郵件生成電子郵件通知。 因此，如果我們想玩用戶數據，我們需要先停用用戶，並在更改完成後激活。 在測試環境中，我們會打亂用戶電子郵件，以便根本不會觸發通知。 由於活躍用戶使用昂貴的許可證，我們無法讓所有用戶在所有測試環境中都活躍。 我們必須管理活躍用戶的子集，例如，僅激活培訓環境中的用戶。
• 對於某些標準對象（例如客戶或案例），非活動用戶只能在授予系統權限“使用非活動所有者更新記錄”後才能分配，但可以將它們分配給例如聯繫人和所有自定義對象。
• 當聯繫人被停用時，所有退出字段都會靜默打開。
• 加載重複的客戶團隊成員或客戶共享對象時，現有記錄將被靜默覆蓋。 但是，當加載重複的商機合作夥伴時，只會添加記錄，從而導致重複。
• 系統字段，例如Created Date 、 Created By ID 、 Last Modified Date 、 Last Modified By ID ，只有在授予新的系統權限“創建記錄時設置審計字段”後才能顯式寫入。
• 字段歷史值更改根本無法遷移。
• 知識文章的所有者不能在加載期間指定，但可以稍後更新。
• 棘手的部分是將內容（文檔、附件）存儲到 Salesforce 中。 有多種方法可以做到這一點（使用附件、文件、Feed 附件、文檔），每種方法都有其優點和缺點，包括不同的文件大小限制。
• 選項列表字段強制用戶選擇一個允許的值，例如，一種帳戶。 但是，當使用 Salesforce API（或任何基於它的工具，例如 Apex Data Loader 或 Informatica Salesforce 連接器）加載數據時，任何值都會傳遞。

清單還在繼續，但底線是：熟悉系統，在做出假設之前了解它可以做什麼和不能做什麼。 不要假設標準行為，尤其是對於核心對象。 始終研究和測試。

9. 不要將 Salesforce 用作數據遷移平台

使用 Salesforce 作為構建數據遷移解決方案的平台非常誘人，尤其是對於 Salesforce 開發人員而言。 數據遷移解決方案的技術與 Salesforce 應用程序定制的技術、相同的 GUI、相同的 Apex 編程語言、相同的基礎架構相同。 Salesforce 具有可以充當表格的對象，以及一種 SQL 語言，即 Salesforce 對象查詢語言 (SOQL)。 但是，請不要使用它； 這將是一個基本的架構缺陷。

Salesforce 是一款出色的 SaaS 應用程序，具有許多不錯的功能，例如高級協作和豐富的自定義功能，但數據的海量處理不是其中之一。 三個最重要的原因是：

• 性能——Salesforce 中的數據處理比 RDBMS 慢幾個等級。
• 缺乏分析功能——Salesforce SOQL 不支持 Apex 語言必須支持的複雜查詢和分析功能，並且會進一步降低性能。
• 架構* – 將數據遷移平台放在特定的 Salesforce 環境中不是很方便。 通常，我們有多個用於特定目的的環境，通常是臨時創建的，以便我們可以將大量時間用於代碼同步。 此外，您還將依賴特定 Salesforce 環境的連接性和可用性。

相反，使用 RDBMS 或 ETL 平台在單獨的實例（可以是雲或本地）中構建數據遷移解決方案。 將其與源系統連接並定位您想要的 Salesforce 環境，將您需要的數據移動​​到您的暫存區域並在那裡進行處理。 這將允許您：

• 充分利用 SQL 語言或 ETL 特性的強大功能。
• 將所有代碼和數據放在一個位置，以便您可以跨所有系統運行分析。
  • 例如，您可以將最新測試 Salesforce 環境中的最新配置與生產 Salesforce 環境中的真實數據相結合。
• 您不會那麼依賴源系統和目標系統的技術，並且可以將您的解決方案重用於下一個項目。

10. 監督 Salesforce 元數據

在項目開始時，我們通常會獲取 Salesforce 字段列表並開始映射練習。 在項目期間，經常會發生應用程序開發團隊向 Salesforce 添加新字段，或者更改某些字段屬性的情況。 我們可以要求應用程序團隊將每次數據模型更改通知數據遷移團隊，但並不總是有效。 為了安全起見，我們需要對所有數據模型的更改進行監督。

執行此操作的常用方法是定期將與遷移相關的元數據從 Salesforce 下載到某個元數據存儲庫中。 一旦有了這個，我們不僅可以檢測數據模型的變化，還可以比較兩個 Salesforce 環境的數據模型。

要下載哪些元數據：

• 帶有標籤和技術名稱以及屬性的對象列表，例如creatable或updatable 。
• 具有屬性的字段列表（最好獲取所有屬性）。
• 選項列表字段的選項列表值列表。 我們將需要它們映射或驗證輸入數據的正確值。
• 驗證列表，以確保新驗證不會對遷移的數據造成問題。

如何從 Salesforce 下載元數據？ 好吧，沒有標準的元數據方法，但有多種選擇：

• 生成企業 WSDL——在 Salesforce Web 應用程序中導航到Setup / API菜單並下載強類型企業 WSDL，它描述了 Salesforce 中的所有對象和字段（但不是選項列表值或驗證）。
• 直接或使用 Java 或 C# 包裝器調用 Salesforce describeSObjects Web 服務（請參閱 Salesforce API）。 這樣，您就可以獲得所需的內容，這是導出元數據的推薦方式。
• 使用互聯網上提供的眾多替代工具中的任何一種。

準備下一次數據遷移

Salesforce 等雲解決方案可立即準備就緒。 如果您對內置功能感到滿意，只需登錄並使用它。 但是，與任何其他雲 CRM 解決方案一樣，Salesforce 給數據遷移主題帶來了需要注意的特定問題，特別是在性能和​​資源限制方面。

將遺留數據轉移到新系統中始終是一段旅程，有時是一段隱藏在過去幾年數據中的歷史之旅。 在本文中，基於十幾個遷移項目，我提出了關於如何遷移遺留數據並成功避免大多數陷阱的十個技巧。

關鍵是要了解數據揭示了什麼。 因此，在您開始數據遷移之前，請確保您的 Salesforce 開發團隊已為您的數據可能存在的潛在問題做好充分準備。